1、(A)系统架构设计师-系统开发基础、软件架构设计、知识产权与标准化(一)及答案解析(总分：100.00，做题时间：90 分钟)一、单项选择题(总题数：46，分数：100.00)1.用户文档主要描述所交付系统的功能和使用方法。下列文档中，_属于用户文档。A需求说明书 B系统设计文档C安装文档 D系统测试计划（分数：2.00）A.B.C.D.2.配置项是构成产品配置的主要元素，其中_不属于配置项。A设备清单 B项目质量报告C源代码 D测试用例（分数：2.00）A.B.C.D.3.一个大型软件系统的需求通常是会发生变化的。以下关于需求变更策略的叙述中，错误的是_。A所有需求变更必须遵循变更控制过程B
2、对于未获得核准的变更，不应该做变更实现工作C完成对某个需求的变更之后，可以删除或者修改变更请求的原始文档D每一个集成的需求变更必须能追溯到一个经核准的变更请求（分数：2.00）A.B.C.D.4.以下关于需求管理的叙述中，正确的是_。A需求管理是一个对系统需求及其变更进行了解和控制的过程B为了获得项目，开发人员可以先向客户做出某些承诺C需求管理的重点在于收集和分析项目需求D软件开发过程是独立于需求管理的活动（分数：2.00）A.B.C.D.5._方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化，比较适合需求变化较大或者开发前期对需求不是很清晰的项目。A信息工程 B结构化C面向对象
3、D敏捷（分数：2.00）A.B.C.D.项目管理工具用来辅助项目经理实施软件开发过程中的项目管理活动，它不能_。_就是一种典型的项目管理工具。（分数：2.00）(1).A覆盖整个软件生存周期B确定关键路径、松弛时间、超前时间和滞后时间C生成固定格式的报表和裁剪项目报告D指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作（分数：1.00）A.B.C.D.(2).A需求分析工具 B成本估算工具C软件评价工具 D文档分析工具（分数：1.00）A.B.C.D.逆向工程导出的信息可以分为 4 个抽象层次，其中_可以抽象出程序的抽象语法树、符号表等信息；_可以抽象出反映程序段功能及程序段之间关系
4、的信息。（分数：2.00）(1).A实现级 B结构级C功能级 D领域级（分数：1.00）A.B.C.D.(2).A实现级 B结构级C功能级 D领域级（分数：1.00）A.B.C.D.6.用例(use case)用来描述系统对事件做出响应时所采取的行动。用例之间是具有相关性的。在一个“订单输入子系统”中，创建新订单和更新订单都需要核查用户账号是否正确。用例“创建新订单”、“更新订单”与用例“核查客户账号”之间是_关系。A包含(include)B扩展(extend)C分类(classification)D聚集(aggregation)（分数：2.00）A.B.C.D.面向对象的设计模型包含以_表示
5、的软件体系结构图，以_表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用于描述流程化处理的活动图等。（分数：2.00）(1).A部署图 B包图C协同图 D交互图（分数：1.00）A.B.C.D.(2).A部署图 B包图C协同图 D交互图（分数：1.00）A.B.C.D.7.系统输入设计中应尽可能地考虑人的因素，以下关于输入设计的一般原理中，错误的是_。A只让用户输入变化的数据B使用创新的模式吸引用户的眼球C表格中各个数据项应有提示信息D尽可能使用选择而不是键盘输入的方式获取数据（分数：2.00）A.B.C.D.8.系统测试将软件、硬件、网络等其他因素结合，对整个软件进行测试。_不是系统
6、测试的内容。A路径测试 B可靠性测试C安装测试 D安全测试（分数：2.00）A.B.C.D.9.软件测试是为了发现错误而执行程序的过程。黑盒测试法主要根据_来设计测试用例。A程序内部逻辑 B程序内部功能C程序数据结构 D程序流程图（分数：2.00）A.B.C.D.10.详细的项目范围说明书是项目成功的关键。_不应该属于范围定义的输入。A项目章程 B项目范围管理计划C需求文件 D项目文档管理方案（分数：2.00）A.B.C.D.11.项目时间管理包括使项目按时完成所必需的管理过程，活动定义是其中的一个重要过程。通常可以使用_来进行活动定义。A鱼骨图 B工作分解结构(WBS)C层次分解结构 D功能
7、分解图（分数：2.00）A.B.C.D.12.在实际的项目开发中，人们总是希望使用自动工具来执行需求变更控制过程。下列描述中，_不是这类工具所具有的功能。A可以定义变更请求的数据项以及变更请求生存期的状态转换图B记录每一种状态变更的数据，确认做出变更的人员C可以加强状态转换图使经授权的用户仅能做出所允许的状态变更D定义变更控制计划，并指导设计人员按照所制定的计划实施变更（分数：2.00）A.B.C.D.13.需求管理是 CMM 可重复级中的 6 个关键过程域之一，其主要目标是_。A对于软件需求，必须建立基线以进行控制，软件计划、产品和活动必须与软件需求保持一致B客观地验证需求管理活动符合规定的
8、标准、程序和要求C策划软件需求管理的活动，识别和控制已获取的软件需求D跟踪软件需求管理的过程、实际结果和执行情况（分数：2.00）A.B.C.D.在 RUP 中采用“4+1”视图模型来描述软件系统的体系结构。在该模型中，最终用户侧重于_，系统工程师侧重于_。（分数：4.00）(1).A实现视图B进程视图C逻辑视图D部署视图（分数：2.00）A.B.C.D.(2).A实现视图B进程视图C逻辑视图D部署视图（分数：2.00）A.B.C.D.14._把整个软件开发流程分成多个阶段，每一个阶段都由目标设定、风险分析、开发和有效性验证以及评审构成。A原型模型 B瀑布模型C螺旋模型 DV 模型（分数：2.
9、00）A.B.C.D.软件开发环境是支持软件产品开发的软件系统，它由软件工具集和环境集成机制构成。环境集成机制包括：提供统一的数据模式和数据接口规范的数据集成机制；支持各开发活动之间通信、切换、调度和协同的_；为统一操作方式提供支持的_。（分数：4.00）(1).A操作集成机制B控制集成机制C平台集成机制D界面集成机制（分数：2.00）A.B.C.D.(2).A操作集成机制B控制集成机制C平台集成机制D界面集成机制（分数：2.00）A.B.C.D.15.软件的横向重用是指重用不同应用领域中的软件元素。_是一种典型的、原始的横向重用机制。A对象 B构件C标准函数库 D设计模式（分数：2.00）A
10、.B.C.D.16.下列关于不同软件开发方法所使用的模型的描述中，正确的是_。A在进行结构化分析时，必须使用数据流图和软件结构图这两种模型B采用面向对象开发方法时，可以使用状态图和活动图对系统的动态行为进行建模C实体联系图(E-R 图)是在数据库逻辑结构设计时才开始创建的模型DUML 的活动图与程序流程图的表达能力等价（分数：2.00）A.B.C.D.17.系统输入设计中，采用内部控制方式以确保输入系统数据的有效性，_用于验证数据是否位于合法的取值范围。A数据类型检查B自检位C域检查D格式检查（分数：2.00）A.B.C.D.系统测试由若干个不同的测试类型组成，其中_检查系统能力的最高实际限度
11、，即软件在一些超负荷情况下的运行情况；_主要检查系统的容错能力。（分数：4.00）(1).A强度测试 B性能测试C恢复测试 D可靠性测试（分数：2.00）A.B.C.D.(2).A强度测试 B性能测试C恢复测试 D可靠性测试（分数：2.00）A.B.C.D.18.软件产品配置是指一个软件产品在生存周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合的每一个元素称为该产品配置中的一个配置项。下列不应该属于配置项的是_。A源代码清单 B设计规格说明书C软件项目实施计划 DCASE 工具操作手册（分数：2.00）A.B.C.D.19.软件质量保证是软件项目控制的重要手段
12、，_是软件质量保证的主要活动之一。A风险评估 B软件评审C需求分析 D架构设计（分数：2.00）A.B.C.D.20.利用需求跟踪能力链(traceability link)可以跟踪一个需求使用的全过程，也就是从初始需求到实现的前后生存期。需求跟踪能力链有 4 类：追溯到需求、从需求追溯、回溯到需求、从需求回溯，如图所示。（分数：2.00）A.B.C.D.21.通常有两种常用的需求定义方法：严格定义方法和原型方法。下述的各种假设条件中，_不适合使用严格定义方法进行需求定义。A所有需求都能够被预先定义B开发人员与用户之间能够准确而清晰地交流C需求不能在系统开发前被完全准确地说明D采用图形(或文字
13、)充分体现最终系统（分数：2.00）A.B.C.D.22.下列关于软件需求管理或需求开发的叙述中，正确的是_。A所谓需求管理是指对需求开发的管理B需求管理包括：需求获取、需求分析、需求定义和需求验证C需求开发是将用户需求转化为应用系统成果的过程D在需求管理中，要求维持对用户原始需求和所有产品构件需求的双向跟踪（分数：2.00）A.B.C.D.RUP 是一个二维的软件开发模型，其核心特点之一是_。RUP 将软件开发生存周期划分为多个循环(cycle)，每个循环由 4 个连续的阶段组成，每个阶段完成确定的任务。设计及确定系统的体系结构，制订工作计划及资源要求是在_阶段完成的。（分数：2.00）(1
14、).A数据驱动 B模型驱动C用例驱动 D状态驱动（分数：1.00）A.B.C.D.(2).A初始(inception) B细化(elaboration)C构造(construction) D移交(transition)（分数：1.00）A.B.C.D.在面向对象设计中，用于描述目标软件与外部环境之间交互的类被称为_，它可以_。（分数：3.00）(1).A实体类 B边界类C模型类 D控制类（分数：1.50）A.B.C.D.(2).A表示目标软件系统中具有持久意义的信息项及其操作B协调、控制其他类完成用例规定的功能或行为C实现目标软件系统与外部系统或外部设备之间的信息交流和互操作D分解任务并把子任
15、务分派给适当的辅助类（分数：1.50）A.B.C.D.23.最少知识原则(也称为迪米特法则)是面向对象设计原则之一，是指一个软件实体应当尽可能少地与其他实体发生相互作用。这样，当一个实体被修改时，就会尽可能少地影响其他的实体。下列叙述中，“_”不符合最少知识原则。A在类的划分上，应当尽量创建松耦合的类B在类的设计上，只要有可能，一个类型应当设计成不变类C在类的结构设计上，每个类都应当尽可能提高对其属性和方法的访问权限D在对其他类的引用上，一个对象对其他对象的引用应当降到最低（分数：2.00）A.B.C.D.24.下列关于各种软件开发方法的叙述中，错误的是_。A结构化开发方法的缺点是开发周期较长
16、，难以适应需求变化B可以把结构化方法和面向对象方法结合起来进行系统开发，使用面向对象方法进行自顶向下的划分，自底向上地使用结构化方法开发系统C与传统方法相比，敏捷开发方法比较适合需求变化较大或者开发前期需求不是很清晰的项目，以它的灵活性来适应需求的变化D面向服务的方法以粗粒度、松散耦合和基于标准的服务为基础，增强了系统的灵活性、可复用性和可演化性（分数：2.00）A.B.C.D.25.系统设计是软件开发的重要阶段，_主要是按系统需求说明来确定此系统的软件结构，并设计出各个部分的功能和接口。A外部设计 B内部设计C程序设计 D输入/输出设计（分数：2.00）A.B.C.D.26.快速迭代式的原型
17、开发能够有效控制成本，_是指在开发过程中逐步改进和细化原型直至产生出目标系统。A可视化原型开发 B抛弃式原型开发C演化式原型开发 D增量式原型开发（分数：2.00）A.B.C.D.27.静态分析通过解析程序文本，从而识别出程序语句中可能存在的缺陷和异常之处；静态分析所包含的阶段中，_的主要工作是找出输入变量和输出变量之间的依赖关系。A控制流分析B数据使用分析C接口分析D信息流分析（分数：2.00）A.B.C.D.28.确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。下述各种测试中，_为确认测试。A负载测试和压力测试 B 测试和 测试C随机测试和功能测试 D可靠性测试和性能测试
18、（分数：2.00）A.B.C.D.29.软件_是指改正产生于系统开发阶段而在系统测试阶段尚未发现的错误。A完善性维护B适应性维护C正确性维护D预防性维护（分数：2.00）A.B.C.D.30.以下关于软件生存周期模型的叙述，正确的是_。A在瀑布模型中，前一个阶段的错误和疏漏会隐蔽地带到后一个阶段B在任何情况下使用演化模型，都能在一定周期内由原型演化到最终产品C软件生存周期模型的主要目标是为了加快软件开发的速度D当一个软件系统的生存周期结束之后，它就进入到一个新的生存周期模型（分数：2.00）A.B.C.D.31.螺旋模型将整个软件开发过程分为多个阶段，每个阶段都由目标设定、_、开发和有效性验证
19、以及评审 4 个部分组成。A需求分析 B风险分析C系统设计 D架构设计（分数：2.00）A.B.C.D.基于 UML 的需求分析过程的基本步骤为：利用_表示需求；利用_表示目标软件系统的总体架构。（分数：2.00）(1).A用例及用例图 B包图及类图C剧情及序列图 D组件图及部署图（分数：1.00）A.B.C.D.(2).A用例及用例图 B包图及类图C剧情及序列图 D组件图及部署图（分数：1.00）A.B.C.D.快速应用开发(Rapid Application Development，RAD)通过使用基于_的开发方法获得快速开发。当_时，最适合于采用 RAD 方法。（分数：2.00）(1).
20、A用例 B数据结构C剧情 D构件（分数：1.00）A.B.C.D.(2).A一个新系统要采用很多新技术B新系统与现有系统有较高的互操作性C系统模块化程度较高D用户不能很好地参与到需求分析中（分数：1.00）A.B.C.D.32.以下关于软件开发方法的叙述，错误的是_。A对于较为复杂的应用问题，适合采用形式化方法进行需求分析B形式化方法的优势在于能够精确地表述和研究应用问题及其软件实现C净室软件工程将正确性验证作为发现和排除错误的主要机制D净室软件工程强调统计质量控制技术，包括对客户软件使用预期的测试（分数：2.00）A.B.C.D.软件开发环境应支持多种集成机制。根据功能不同，可以将集成机制分
21、为三个部分：_，用于存储与系统开发有关的信息，并支持信息的交流与共享；_，是实现过程集成和控制集成的基础；_，它的统一性和一致性是软件开发环境的重要特征。（分数：3.00）(1).A算法模型库 B环境信息库C信息模型库 D用户界面库（分数：1.00）A.B.C.D.(2).A工作流与日志服务器B进程通信与数据共享服务器C过程控制与消息服务器D同步控制与恢复服务器（分数：1.00）A.B.C.D.(3).A底层数据结构 B数据处理方法C业务过程模型 D环境用户界面（分数：1.00）A.B.C.D.33.对于违反里氏替换原则的两个类 A 和 B，可以采用的候选解决方案中，正确的是_。A尽量将一些需
22、要扩展的类或者存在变化的类设计为抽象类或者接口，并将其作为基类，在程序中尽量使用基类对象进行编程B创建一个新的抽象类 C，作为两个具体类的超类，将 A 和 B 共同的行为移动到 C 中，从而解决 A 和 B行为不完全一致的问题C将 B 到 A 的继承关系改成组合关系D区分是“Is-a”还是“Has-a”。如果是 Is-a，可以使用继承关系，如果是 Has-a，应该改成组合或聚合关系（分数：2.00）A.B.C.D.34.以下关于黑盒测试用例设计方法的叙述，错误的是_。A边界值分析通过选择等价类边界作为测试用例，不仅重视输入条件边界，而且也必须考虑输出域边界B因果图方法是从用自然语言书写的程序规
23、格说明的描述中找出因(输入条件)和果(输出或程序状态的改变)，可以通过因果图转换为判定表C正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率D等价类划分法根据软件的功能说明，对每一个输入条件确定若干个有效等价类和无效等价类，但只能为有效等价类设计测试用例（分数：2.00）A.B.C.D.35.以下关于软件测试工具的叙述，错误的是_。A静态测试工具可用于对软件需求、结构设计、详细设计和代码进行评审、走查和审查B静态测试工具可对软件的复杂度分析、数据流分析、控制流分析和接口分析提供支持C动态测试工具可用于软件的覆盖分析和性能分
24、析D动态测试工具不支持软件的仿真测试和变异测试（分数：2.00）A.B.C.D.(A)系统架构设计师-系统开发基础、软件架构设计、知识产权与标准化(一)答案解析(总分：100.00，做题时间：90 分钟)一、单项选择题(总题数：46，分数：100.00)1.用户文档主要描述所交付系统的功能和使用方法。下列文档中，_属于用户文档。A需求说明书 B系统设计文档C安装文档 D系统测试计划（分数：2.00）A.B.C. D.解析：解析 用户文档主要描述所交付系统的功能和使用方法，并不关心这些功能是怎样实现的。用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。用户文档一般包括以下内容。功
25、能描述：说明系统能做什么。安装文档：说明怎样安装这个系统，以及怎样使系统适应特定的硬件配置。使用手册：简要说明如何着手使用这个系统(通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误是怎样恢复和重新启动的)。参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整，因此通常使用形式化的描述技术)。操作员指南(如果需要有系统操作员的话)：说明操作员应如何处理使用中出现的各种情况。试题中只有安装文档属于用户文档，其他的需求说明书、系统设计文档、系统测试计划均属于开发文档。2.配置项是构成产品配置的主要元素，其中_
26、不属于配置项。A设备清单 B项目质量报告C源代码 D测试用例（分数：2.00）A. B.C.D.解析：解析 信息系统在其开发、运行、维护的过程中会得到许多阶段性的成果，在开发和运行过程中还需要用到多种工具软件，所有这些信息项需要得到妥善的管理，决不能出现混乱，以便在提出某些特定的要求时，将它们进行约定的组合来满足使用的目的。这些信息项是配置管理的对象，称为配置项。IEEE对配置项的定义为：硬件、软件或两者兼有的集合，为配置管理指定的，在配置管理过程中作为一个单独的实体对待。配置项的类型以下内容可以作为配置项进行管理：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软
27、件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。配置项通常可以分成下列 6 种类型。环境类。软件开发、运行和维护的环境，例如，编译器、操作系统、编辑软件、管理系统、开发工具、测试工具、项目管理工具和文档编制工具等。定义类。需求分析与系统定义阶段结束后得到的成果，例如，需求规格说明书、项目管理计划、设计标准和验收测试计划等。设计类。设计阶段得到的成果，例如，系统设计说明书、程序规格说明、数据库设计、编码标准、用户界面设计、测试标准、系统测试计划和用户手册等。编码类。编码及单元测试结束后得到的成果，例如，源代码、目标码、单元测试用例、数据和测试结果等。测试类。系统测试完成后的成果，
28、例如，系统测试用例、测试结果、操作手册和安装手册。维护类。维护阶段产品的成果，以上任何需要变更的配置项。配置项的描述确定了配置项后，还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之，必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构，树状结构上节点之间存在着层次的继承关系。由于配置项除了名称外还有一些其他属性和与其他配置项的关系，因此，它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息(名字、描述、一组资源、实现)唯一地标识。配置项之间的关系有整体和部分的关系及层次关系，也有关联关系。配置项间的关系可以用 MIL(Module Intercon
29、nection Language，模块连接语言)表示，MIL 描述的是配置项间的相互依赖关系，可自动构造系统的任何版本。识别配置项的步骤识别配置项的主要步骤如下。识别配置项。为每个配置项指定唯一性的标识代号。确定每个配置项的重要特征。配置项的特征主要包括作者、日期、类型等。确定配置项进入配置管理的时间。确定每个配置项的拥有者及责任。填写配置管理表。审批配置管理表。CCB 审查配置管理表是否符合配置管理计划的规定，审批配置管理表。3.一个大型软件系统的需求通常是会发生变化的。以下关于需求变更策略的叙述中，错误的是_。A所有需求变更必须遵循变更控制过程B对于未获得核准的变更，不应该做变更实现工作C
30、完成对某个需求的变更之后，可以删除或者修改变更请求的原始文档D每一个集成的需求变更必须能追溯到一个经核准的变更请求（分数：2.00）A.B.C. D.解析：解析 在软件项目中，需求的变化是不可避免的。需求变更可能来自解决方案提供商、用户或产品供应商等外部因素，也可能来源于项目团队内部。对于项目团队而言，无法阻止需求发生变更，他们只能正确地对待变更，按照既定流程管理变更，尽量降低变更对项目成本、进度和质量的负面影响。需求基线需求开发的结果应该有项目视图和范围文档、用例文档和 SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间构成了软件需求的一
31、个约定，它是需求开发和需求管理之间的桥梁。基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE 的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS 文档通过评审，其中的错误已经被发现并纠正，则变成一个基线。根据国家标准计算机软件配置管理计划规范(GB/T 12505-1990)的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的 SRS 属于
32、指派基线。开发团队可以根据已知的需求基线来区分“旧需求”和“新需求”。一旦建立了需求基线，很容易对新需求进行识别和管理，可以把新需求和已有的基线加以比较，确定适合它的位置以及它是否会与其他需求产生冲突。如果接受新需求，就可以管理它的变更过程。需求的状态从需求的整个生命周期来看，其状态的变化如图所示。在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容是对需求的实现。4.以下关于需求管理的叙述中
33、，正确的是_。A需求管理是一个对系统需求及其变更进行了解和控制的过程B为了获得项目，开发人员可以先向客户做出某些承诺C需求管理的重点在于收集和分析项目需求D软件开发过程是独立于需求管理的活动（分数：2.00）A. B.C.D.解析：解析 软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定(Agreement)。需求约定是需求开发和需求管理之间的桥梁。需求管理是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的初稿，需求管理活
34、动就开始了。需求管理强调：控制对需求基线的变动；保持项目计划与需求一致；控制单个需求和需求文档的版本情况；管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；跟踪基线中的需求状态。CMMI 描述了软件处理能力的 5 个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有6 个关键过程域 KPA(Key Process Areas)。需求管理是其中之一，它的目标是：为软件需求建立一个基线，提供给软件工程和管理使用；软件计划、产品和活动与软件需求保持一致。关于需求管理过程域内的原则和策略，可以参考如下。需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件
35、需求，或者已由更高一级的系统给定了需求。一旦需求获得并且文档化了，软件开发组和有关的团队(例如质量保证和测试组)需要评审文档。发现问题应与客户或者其他需求源协商解决。软件开发计划是基于已确认的需求。开发人员在向客户以及有关部门承诺(Commitment)某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。也许不得不面对由于技术因素或者进度等原因承诺一些不现实的需求，但是决不要承诺任何无法实现的需求。关键处理领域同样建议通过版本控制和变更控制来管理需求文档。版本控制确保随时能知道在项目开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的规范的方式来统一需求变更，并且基于业务
36、和技术的因素来同意或者反对建议的变更。当在开发中修改、增加、减少需求时，软件开发计划应该随时更新，确保与新的需求保持一致。5._方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化，比较适合需求变化较大或者开发前期对需求不是很清晰的项目。A信息工程 B结构化C面向对象 D敏捷（分数：2.00）A.B.C.D. 解析：解析 敏捷方法是从 20 世纪 90 年代开始逐渐引起广泛关注的一些新型软件开发方法，以应对快速变化的需求。虽然它们的具体名称、理念、过程、术语都不尽相同，但相对于“非敏捷”而言，它们更强调开发团队与用户之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的
37、团队等，也更注重人的作用。敏捷宣言2001 年，Kent Beck 等人组织了敏捷联盟，阐述了敏捷开发的原则，试图强调灵活性在快速且有效地开发软件中所发挥的作用。他们共同签署了敏捷软件开发宣言，该宣言认为，个体和交互胜过过程和工具；可工作的软件胜过大量的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。敏捷方法强调：让客户满意和软件尽早增量发布、小而高度自主的项目团队、非正式的方法、最小化软件工程工作产品以及整体精简开发。产生这种情况的原因是，在绝大多数软件开发过程中，提前预测哪些需求是稳定的和哪些需求会变化非常困难；对于软件项目构建来说，设计和实现是交错的；从指定计划的角度来看，分析、设计、
38、实现和测试并不容易预测；可执行原型和部分实现的可运行系统是了解用户需求和反馈的有效媒介。目前，主要的敏捷方法有极限编程(eXtreme Programming，XP)、自适应软件开发(Adaptive Software Development，ASD)、水晶方法(Crystal)、特性驱动开发(Feature Driven Development，FDD)、动态系统开发方法(Dynamic SystemsDevelopment Method，DSDM)测试驱动开发(Test-Driven Development，TDD)、敏捷数据库技术(Agile Database Techniques，AD
39、T)和精益软件开发(Lean SoftwareDevelopment)等。虽然这些过程模型在实践上有差异，但都是遵循了敏捷宣言或者是敏捷联盟所定义的基本原则。这些原则包括客户参与、增量式移交、简单性、接受变更、强调开发人员的作用和及时反馈等。敏捷方法的特点敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。在敏捷方法中，软件项目的构建被切分成多个子项目，各个子项目成果都经过测试，具备集成和可运行的特征。在敏捷方法中，从开发者的角度来看，主要的关注点有短平快的会议、小版本发布、较少的文档、合作为重、 客户直接参与、自动化测试、适应性计划调整和结对编程；从管理者的角度来看，主要的关注点有测试驱动开
40、发、持续集成和重构。近年来，虽然敏捷方法发展得较快，但在实施的过程中，也暴露出来很多问题，一些敏捷方法的基本原则很难实施，主要体现在以下四个方面。客户参与往往依赖于客户参与的意愿和客户自身的代表性。团队成员的性格可能不适合激烈的投入，可能无法做到与其他成员之间的良好沟通。对系统的变更做出优先级排序可能是极端困难的。维护系统的简洁性往往需要额外的工作，但迫于时间表的压力，可能没有时间执行系统简化过程。与 RUP 相比，敏捷方法的周期可能更短。敏捷方法在几周或几个月的时间内完成相对较小的功能，强调的是能尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强，并且更加强调刚队中的高度协作
41、。相对而言，敏捷方法主要适用于以下场合：项目团队的人数不能太多，适合于规模较小的项目。项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合。高风险项目的实施。从组织结构的角度看，组织结构的文化、人员、沟通性决定了敏捷方法是否适用。与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但是精干、开发人员所做的决定得到认可、环境设施满足团队成员之间快速沟通的需要。项目管理工具用来辅助项目经理实施软件开发过程中的项目管理活动，它不能_。_就是一种典型的项目管理工具。（分数：2.00）(1).A覆盖整个软件生存周
42、期B确定关键路径、松弛时间、超前时间和滞后时间C生成固定格式的报表和裁剪项目报告D指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作（分数：1.00）A.B.C.D. 解析：(2).A需求分析工具 B成本估算工具C软件评价工具 D文档分析工具（分数：1.00）A.B. C.D.解析：解析 软件管理过程和软件支持过程往往要涉及软件生存周期中的多个活动，软件管理和软件支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质高效地完成。辅助软件管理和软件支持的工具有很多，其中常用的工具有项目管理工具、配置管理工具、软件评价工具等。项目管理工具项目管理工具用来辅助软件的项目
43、管理活动。通常项目管理活动包括项目的计划、调度、通信、成本估算、资源分配及质量控制等。一个项目管理工具通常把重点放在某一个或某几个特定的管理环节上，而不提供对管理活动包罗万象的支持。例如成本估算工具，采用某种成本估算模型(如 COCOMO 模型)对项目的成本进行估算。它可以通过间接的测量(如对代码行和功能点的测量)来估算项目的规模大小，并描述总的项目特征，如问题的复杂度、开发组经验和过程成熟度等，然后按一定的估算模型估算出项目的工作量、工期和开发人员数等。当项目截止期限变更时，可检测它对整个开发成本的影响。配置管理工具配置管理工具用于辅助完成软件配置项的标识、版本控制、变化控制、审计和状态统计
44、等基本任务，使各配置项的存取、修改和系统生成易于实现，从而简化审计过程，改进状态统计，减少错误，提高系统的质量。软件评价工具软件评价工具用于辅助管理人员进行软件质量保证的有关活动。它通常可按某个软件质量模型(如 McCall软件质量模型，ISO 软件质量度量模型等)对被评价的软件进行度量，然后得到相关的软件评价报告。目前许多度量指标还不能定量化，需要通过专家评分，再将得分送给软件评价工具。对一些已经定量化的度量指标则可利用评价工具自动获取。有的评价工具还可分析被评价程序的程序结构，根据某种软件复杂性模型(如：Mc-Cabe 的环路复杂度等)对被评价的程序进行复杂性度量。软件评价工具有助于软件的
45、质量控制，对确保软件的质量有重要的作用。软件开发工具的评价和选择现在各类软件开发工具十分丰富，有免费的，有价格便宜的，也有昂贵的。评价和选择适合本人、本单位、本项目的软件开发工具，可以根据以下标准来衡量软件开发工具的优劣。功能软件开发工具不仅要实现所遵循的功能需求，支持用户所选定的开发方法，还应能检查与之相关的方法学能否正确执行，并保证产生与方法学一致的输出结果。易用性软件开发工具应有十分友好的用户界面，用户乐于使用；工具应能剪裁和定制，以适应特定用户的需要；工具应能提示用户的交互操作，提供简单有效的执行方式；工具还应能检查用户的操作错误，尽可能自动改正错误。稳健性一个好的软件开发工具应能长期
46、可靠地使用，并能适应环境或其他条件变化的要求；即使在非法操作或故障情况下，也不应导致严重后果。硬件要求和性能软件开发工具的性能(如响应速度、占用存储空间的大小等)，将直接影响工具的使用效果。合理的性能和对硬件的要求可以使机器的资源能被有效地加以利用，使用户的投资发挥最大的作用。服务和支持软件开发工具的生产厂商应能为该工具提供有效的技术服务(如培训、咨询、版本更新等)，工具的文档应该齐全、通俗易懂。逆向工程导出的信息可以分为 4 个抽象层次，其中_可以抽象出程序的抽象语法树、符号表等信息；_可以抽象出反映程序段功能及程序段之间关系的信息。（分数：2.00）(1).A实现级 B结构级C功能级 D领
47、域级（分数：1.00）A. B.C.D.解析：(2).A实现级 B结构级C功能级 D领域级（分数：1.00）A.B.C. D.解析：解析 逆向工程与重构工程是目前预防性维护采用的主要技术。逆向工程术语源于硬件制造业，相互竞争的公司为了了解对方设计和制造工艺的机密，在得不到设计和制造说明书的情况下，通过拆卸实物获取信息。软件的逆向工程也基本类似，不过通常“解剖”的不仅是竞争对手的程序，而且包括本公司多年前的产品，此时得不到设计“机密”的主要障碍是缺乏文档。因此，所谓软件的逆向工程就是分析已有的程序，寻求比源代码更高级的抽象表现形式。一般认为，凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。与之相关的概念是：重构(restructuring)，指在同一抽象级别上转换系统描述形式；设计恢复(design recovery)，指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计的信息(不一定是原设计)；重构工程(re-engineering)，也称修复和改造工程，它是在逆向工程所获信息的基础上修改或重构已有的系统，产生系统的一个新版本。恢复信息的级别逆向工程导出的信息可分为如下 4 个抽象层次：
