2021-07-12-软考备考－系统构架师－13－开发管理相关试题整理

说明#

1 整理2009~2016年系统构架师”开发管理”题目
2 内容见文档：”考点按章节整理\第 13 章 开发管理\开发管理.docx”
3 更新文档：”各年例题分类.xlsx”

项目地址#

https://gitee.com/lxmuyu/soft_examination.git

考题分布#

开发管理
目录
开发管理 1
1 项目的范围、时间与成本 2
1.1 项目范围管理 2
1.2 项目成本管理 3
1.3 项目时间管理 4
2 配置管理与文档管理 5
2.1 软件配置管理的概念 5
2.2 软件配置管理的解决方案 8
2.3 软件文档管理 8
3 软件需求管理 9
3.1 需求变更 12
3.2 需求跟踪 17
4 软件开发的质量与风险 18
4.1 软件质量管理 18
4.2 项目风险管理 19
5 人力资源管理 19
6 软件的运行与评价 19
7 软件过程改进 19
7.1 CMM 19
7.2 CMMI 20
8 软件系统工具 20

1　项目的范围、时间与成本
1.1　项目范围管理
 详细的项目范围说明书是项目成功的关键。(22)不应该属于范围定义的输入。
2010年(22)
A.项目章程
B.项目范围管理计划
C.批准的变更申请
D.项目文档管理方案
【答案】D 【解析】

在初步项目范围说明书中己文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范围说明书，是项目成功的关键。范围定义的输入包括以下内容：

①项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。

②项目范围管理计划。 ③组织过程资产。 ④批准的变更申请。 所以项目文档管理方案不属于范围定义的输入。

 详细的项目范围说明书是项目成功的关键，(25)不属于项目范围定义的输入。
2013年(25)
A.项目章程
B.项目范围管理计划
C.批准的变更申请
D.项目文档管理方法
【答案】D 【解析】

本题考查软件项目开发管理方面的基础知识。在初始项目范围说明书&已文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范围说明书，是项目成功的关键。范围定义的输入包括以下内容：

①项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。

②项目范围管理计划。 ③组织过程资产。 ④批准的变更申请。

 关于项目范围管理描述，正确的是（25）。
2015年(25)
A.项目范围是指信息系统产品或者服务所应包含的功能
B.项目范围描述是产品范围说明书的重要组成部分
C.项目范围定义是信息系统要求的度量
D.项目范围定义是生产项目计划的基础
【答案】D 【解析】本题考查软件项目范围管理方面的基础知识。

项目范围是为了达到项目目标，为了交付具有某种特制的产品和服务，项目所规定要做的。在信息系统项目中，产品范围是指信息系统产品或者服务所应该包含的功能，项目范围是指为了能够交付信息系统项目所必须做的工作。产品范围是项目范围的基础，产品的范围定义是信息系统要求的度量，而项目范围的定义是生产项目计划的基础。产品范围描述是项目范围说明书的重要组成部分。

1.2　项目成本管理
 项目的成本管理中，（22）将总的成本估算分配到各项活动和工作包上，来建立一个成本的基线。
2016年(22)
A.成本估算
B.成本预算
C.成本跟踪
D.成本控制
【答案】B
【解析】本题考查成本预算的定义。
1.3　项目时间管理
 项目时间管理包括使项目按时完成所必需的管理过程，活动定义是其中的一个重要过程。通常可以使用(23)来进行活动定义。
2010年(23)
A.鱼骨图
B.工作分解结构(WBS)
C.层次分解结构
D.功能分解
【答案】B 【解析】

项目时间管理包括使项目按时完成所必需的管理过程。项目时间管理中的过程包括：活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制。

为了得到工作分解结构(Work Breakdown

Structure，WBS)中最底层的交付物，必须执行一系列的活动。对这些活动的识别以及归档的过程就是活动定义。

鱼骨图(也称为Ishikawa图)是一种发现问题“根本原因”的方法，通常用来进行因果分析。

 活动定义是项目时间管理中的过程之一，(26)是进行活动定义时通常使用的一种工具。
2013年(26)
A.Gantt图
B.活动图
C.工作分解结构（WBS)
D.PERT图
【答案】C 【解析】

项目时间管理包括使项目按时完成所必须的管理过程。项目时间管理中的过程包括：活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制。为了得到工作分解结构（Work Break down Structure,WBS)中最底层的交付物，必须执行一系列的活动，对这些活动的识别以及归档的过程就叫做活动定义。
2　配置管理与文档管理
2.1　软件配置管理的概念
 配置项是构成产品配置的主要元素，其中（22）不属于配置项。
2009年(22)
A.设备清单
B.项目质量报告
C.源代码
D.测试用例
【答案】A 【解析】 配置项是构成产品配置的主要元素，配置项主要有以下两大类： (1)属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等; (2)属于项目管理和机构支撑过程域产生的文档：如工作计划、项目质量报告和项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。所以设备清单不属于配置项。

 软件产品配置是指一个软件产品在生存周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合的每一个元素称为该产品配置中的—个配置项。下列不应该属于配置项的是（22)。
2011年(22)
A.源代码清单
B.设计规格说明书
C.软件项目实施计划
D.CASE工具操作手册
【答案】D 【解析】本题考查软件配置管理方面的基础知识。

软件产品配置是指一个软件产品在生存周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合的每一个元素称为该产品配置中的

—个配置项。配置项主要有以下两大类。 属于产品组成部分的工作成果，如需求文档、设计文档、源代码和测试用例等。

属于项目管理和机构支撑过程域产生的文档，如工作计划、项目质量报、项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。

在题目的选项中，CASE工具操作手册不属于上述两类，所以它不属于配置项。

 项目配置管理中，配置项的状态通常包括（26）。
2015年(26)
A.草稿、正式发布和正在修改
B.草稿、技术评审和正式发布
C.草稿，评审或审批、正式发布
D.草稿、正式发布和版本变更
【答案】A 【解析】本题考查软件项目配置管理方面的基础知识。

在配置管理中，所有的配置项都应列入版本控制的范畴。配置项的状态通常有3种，分别是草稿、正式发布和正在修改。

 （23）是关于项目开发管理正确的说法。
2016年(23)
A.需求文档、设计文档属于项目管理和机构支撑过程域产生的文档
B.配置管理是指一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合
C.项目时间管理中的过程包括活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制
D.操作员指南属于系统文档
【答案】C
【解析】 配置管理是PMBOK、IS09000和CMMI中的重要组成元素，它在产品开发的生命周期中，提供了结构化的、有序化的、产品化的管理方法，是项目管理的基础工作。配置管理是通过技术和行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。信息系统开发过程中的变更以及相应的返工会对产品的质量有很大的影响。产品配置是指一个产品在其生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项（ConfigurationItem，CI)，配置项主要有两大类： 属于产品组成部分的工作成果，如需求文档、设计文档、源代码、测试用例等。属于项目管理和机构支撑过程域产生的文档，如工作计划、项目质量报告、项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。用户文档：用户文档是用户了解系统的第一步，它可以让用户获得对系统的准确的初步印象。用户文档至少应该包括下述5方面的内容：(1)功能描述：说明系统能做什么； (2)安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；(3)使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误时怎样恢复和重新启动）；(4)参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）；(5)操作员指南（如果需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况。
系统文档：所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。

2.2　软件配置管理的解决方案
2.3　软件文档管理
 用户文档主要描述所交付系统的功能和使用方法。下列文档中，(21)属于用户文档。
2009年(21)
A.需求说明书
B.系统设计
C.安装文档
D.系统测试计划
【答案】C 【解析】

用户文档主要描述所交付系统的功能和使用方法,并不关心这些功能是怎样实现的。用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。用户文档至少应该包括下述5方面的内容。 ①功能描述：说明系统能做什么。 ②安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。③使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明.怎样使用常用的系统功能，并说明用户操作错误是怎样恢复和重新启动的）。④参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）。⑤操作员指南（如果需要有系统操作员的话)：说明操作员应如何处理使用中出现的各种情况。系统文档是从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。

3　软件需求管理
 项目管理工具用来辅助项目经理实施软件开发过程中的项目管理活动，它不能 (26)。(27)就是一种典型的项目管理工具。
2009年(26)
A.覆盖整个软件生存周期
B.确定关键路径、松弛时间、超前时间和滞后时间
C.生成固定格式的报表和裁剪项目报告
D.指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作
2009年(27)
A.需求分析工具
B.成本估算工具
C.软件评价工具
D.文档分析工具
【答案】D B 【解析】 项目管理工具用来辅助软件的项目管理活动。通常项目管理活动包括项目的计划、调度、通信、成本估算、资源分配及质量控制等。一个项目管理工具通常把重点放在某一个或某几个特定的管理环节上，而不提供对管理活动包罗万象的支持。项目管理工具具有以下特征： (1) 覆盖整个软件生存周期； (2) 为项目调度提供多种有效手段； (3)利用估算模型对软件费用和工作量进行估算； (4) 支持多个项目和子项目的管理； (5) 确定关键路径，松弛时间，超前时间和滞后时间； (6)对项目组成员和项目任务之间的通信给予辅助； (7) 自动进行资源平衡； . (8) 跟踪资源的使用； (9)生成固定格式的报表和剪裁项目报告。 成本估算工具就是一种典型的项目管理工具。

 以下关于需求管理的叙述中，正确的是（24）。
2009年(24)
A.需求管理是一个对系统需求及其变更进行了解和控制的过程
B.为了获得项目，开发人员可以先向客户做出某些承诺
C.需求管理的重点在于收集和分析项目需求
D.软件开发过程是独立于需求管理的活动
【答案】A 【解析】

需求管理是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理计划，一旦形成了需求文档的初稿，需求管理活动就开始了。关于需求管理过程域内的原则和策略，可以参考：①需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求，或者已由更高一级的系统给定了需求。②开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。③关键处理领域同样建议通过版本控制和变更控制来管理需求文档。

 下列关于软件需求管理或需求开发的叙述中，正确的是（26)。
2011年(26)
A.所谓需求管理是指对需求开发的管理
B.需求管理包括：需求获取、需求分析、需求定义和需求验证
C.需求开发是将用户需求转化为应用系统成果的过程
D.在需求管理中，要求维持对用户原始需求和所有产品构件需求的双向跟踪
【答案】D 【解析】本题考查软件需求工程方面的基础知识。

软件需求工程是包括创建和维护软件需求文档所必须的一切活动的过程，可以分为需求开发和需求管理两大工作。需求开发包括需求获取、需求分析、编写需求规格说明书（需求定义）和需求验证4个阶段。在需求开发阶段需要确定软件所期望的用户类型，

获取各种用户类型的需求，了解实际的用户任务和目标，以及这些任务所支持的业务 需求。

需求管理是一个对系统需求变更、了解和控制的过程，逋常包括定义需求基线、处理需求变更和需求跟踪方面的工作。需求管理强调：控制对需求基线的变动；保持项目计划与需求的一致；控制单个需求和需求文档的版本情况；管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；跟踪基线中的需求状态。

需求开发与需求管理是相辅相成的，需求开发是主线、目标；需求管理是支持、保障。

 通常有两种常用的需求定义方法：严格定义方法和原型方法。下述的各种假设条件中，“(25)”不适合使用严格定义方法进行需求定义。
2011年(25)
A.所有需求都能够被预先定义
B.开发人员与用户之间能够准确而清晰地交流
C.需求不能在系统开发前被完全准确地说明
D.采用图形（或文字）充分体现最终系统
【答案】C 【解析】 需求定义的过程也就是形成需求规格说明书的过程，通常有两种需求定义的方法： 严格定义方法和原型方法。

严格定义方法也称为预先定义，需求的严格定义建立在以下基本假设之上：

①所有需求都能够被预先定义。这意味着在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。但这种假设在许多场合是不能成立的。

②开发人员与用户之间能够准确而清晰地交流。

③采用图形（或文字）可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流与沟通的主要工具是定义报告，包括文字、图形、逻辑规则和数据字典等技术工具。

原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。采用原型方法时需注意一下几个问题：

①并非所有的需求都能在系统开发前被准确地说明。 ②项目干系人之间通常都存在交流上的困难。 ③需要实际的、可供用户参与的系统模型。

④有合适的系统开发环境。 ⑤反复是完全需要和值得提倡的。需求一旦确定，就应该遵从严格定义的方法。

3.1　需求变更
 —个大型软件系统的需求通常是会发生变化的。以下关于需求变更策略的叙述中错误的是（23）
2009年(23)
A.所有需求变更必须遵循变更控制过程
B.对于未获得核准的变更，不应该做变更实现工作
C.完成了对某个需求的变更之后，就可以删除或者修改变更请求的原始文档
D.每一个集成的需求变更必须能追溯到一个经核准的变更请求
【答案】C 【解析】 —个大型软件系统的需求通常是会发生变化的。在进行需求变更时，可以参考以下的需求变更策略： (1)所有需求变更必须遵循变更控制过程： (2) 对于未获得批准的变更，不应该做设计和实现工作； 2009年(3)
变更应该由项目变更控制委员会决定实现哪些变更； (4) 项目风险承担者应该能够了解变更数据库的内容； (5)决不能从数据库中删除或者修改变更请求的原始文档； (6) 每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

 一个大型软件系统的需求总是有变化的。为了降低项目开发的风险，需要一个好的变更控制过程。如下图所示的需求变更管理过程中，①②③处对应的内容应是（28）；自动化工具能够帮助变更控制过程更有效地运作，（29）是这类工具应具有的特性之一。
2015年(28)
A.问题分析与变更描述，变更分析与成本计算，变更实现
B.变更描述与变更分析，成本计算，变更实现
C.问题分析与变更描述，变更分析，变更实现
D.变更描述，变更分析，变更实现
2015年(29)
A.自动维护系统的不同版本
B.支持系统文档的自动更新
C.自动判定变更是否能够实施
D.记录每一个状态变更的日期及变更者

【答案】A D 【解析】

一个大型的软件系统的需求总是有变化的。对许多项目来说，系统软件总需要不断完善，一些需求的改进是合理的而且不可避免，要使得软件需求完全不变更，也许是不可能的，但毫无控制的变更是项目陷入混乱、不能按进度完成，或者软件质量无法保证的主要原因之一。一个好的变更控制过程，给项目风险承担者提供了正式的建议需求变更机制，可以通过变更控制过程来跟踪已建议变更的状态，使已建议的变

更确保不会丢失或疏忽。需求变更管理过程如下图所示：

①问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。

②变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且确认，应该进行是否执行这一变更的决策。

③变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。

自动化工具能够帮助变更控制过程更有效地运作。许多团队使用商业问题跟踪工具来收集、存储和管理需求变更。用这样的工具创建的最近提交的变更建议清单，可以用作CCB会议的议程。问题跟踪工具也可以随时按变更状态分类报告出变更请求的数目。

因为可用的工具、厂商和特性总在频繁地变化，所以这里无法给出有关工具的具体建议。但工具应该具有以下几个特性，以支持需求变更过程：

①可以定义变更请求中的数据项； ②可以定义变更请求生命周期的状态转换模型；

③可以强制实施状态转换模型，以便只有授权用户可以做出允许的状态变更； ④可以记录每一个状态变更的日期和做出这一变更的人；

⑤可以定义当提议者提交新请求或请求状态被更新时，哪些人可以自动接收电子邮件通知； ⑥可以生成标准的和定制的报告和图表。

有些商业需求管理工具内置有简单的变更建议系统。这些系统可以将提议的变更与某一特定的需求联系起来，这样无论什么时候，只要有人提交了一个相关的变更请求，负责需求的每个人都会收到电子邮件通知。

 下列叙述中，不满足好的需求陈述要求的是（27）。
2015年(27)
A.每一项需求都必须完整、准确地描述即将要开发的功能
B.需求必须能够在系统及其运行环境的能力和约束条件内实现
C.每一项需求记录的功能都必须是用户的真正的需要
D.所有需求都应被视为同等重要
【答案】D 【解析】 理想情况下，每一项用户、业务需求和功能需求都应具备下列性质。

完整性。每一项需求都必须完整地描述即将交付使用的功能。它必须包含开发人员设计和实现这项功能需要的所有信息。

正确性。每一项需求都必须准确地描述将要开发的功能。判断正确性的参考是需求来源，如实际用户和高级的系统需求。如果一项软件需求与其相对应的系统需求发生冲突，这是不正确的。

可行性。需求必须能够在系统及其运行环境的已知能力和约束条件内实现。

必要性。每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或标准而必须具备的功能。每项需求都必须来源于有权定义需求的一方。对每项需求都必须追溯至特定的客户需求的来源，例如用例、业务规则或者其他来源。

有优先次序。为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。如果所有需求都被视为同等重要，项目经理就很难采取措施应对预算削减、进度拖后、人员流失或开发过程中需求增加等情况。

无歧义。一项需求声明对所有读者应该只有一种一致的解释，编写需求时应该使用用户所在领域的、简洁明了的语言。应该在词汇表中列出所有专用的和可能让用户感到迷惑的术语。

可验证性。如果某项需求不可验证，那么判定其实现的正确与否就成了主观臆断，而不是客观分析。不完备、不一致、不可行或有歧义的需求也是不可验证的。

 （25）是关于需求管理正确的说法。
2016年(25)
A.为达到过程能力成熟度模型第二级，组织机构必须具有3个关键过程域
B.需求的稳定性不属于需求属性
C.需求变更的管理过程遵循变更分析和成本计算、问题分析和变更描述、变更实现的顺序
D.变更控制委员会对项目中任何基线工作产品的变更都可以做出决定
【答案】D
【解析】 过程能力成熟度模型（CMM）在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件处理能力的5个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有 6 个关键过程域 KPA（Key ProcessAreas）。故A选项错误。除了文本，每一个功能需求应该有一些相关的信息与它联系，我们把这些信息称为需求属性。对于一个大型的复杂项目来说，丰富的属性类别显得尤为重要。例如，在文档中考虑和明确如下属性：创建需求的时间、需求的版本号、创建需求的作者、负责认可该软件需求的人员、需求状态、需求的原因和根据、需求涉及的子系统、需求涉及的产品版本号、使用的验证方法或者接受的测试标准、产品的优先级或者重要程度、需求的稳定性。故B选项错误。需求的变更遵循以下流程：(1)问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。
(2)变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。(3)变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。故C选项错误。

3.2　需求跟踪
 利用需求跟踪能力链（traceability link)可以跟踪一个需求使用的全过程，也就是从初始需求到实现的前后生存期。需求跟踪能力链有4类，如下图所示： 其中的①和②分别是(24).
2011年(24)
A.客户需求、软件需求
B.软件需求、客户需求
C.客户需求、当前工作产品
D.软件需求、当前工作产品

【答案】A 【解析】本题考查需求管理方面的基础知识。

需求跟踪包括编制每个需求与系统元素之间的联系文档，这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等。跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必须的工作。

利用需求跟踪能力链(traceabilitylink)可以跟踪一个需求使用的全过程，也就是从初始需求到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征，为了实现跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。

客户需求向前追溯到软件需求。这样就能区分出开发过程中或者开发结束后，由于客户需求变更受到影响的软件需求，这也就可以确保软件需求规格说明包括了所有客户需求。

从软件需求回溯响应的客户需求。这也就是确认每个软件需求的源头。如果使用实例的形式来描述客户需求，那么客户需求与软件需求之间的跟踪情况就是使用实例和功能性需求。

从软件需求向前追溯到下一级工作产品。由于开发过程中系统需求转变为软件需求、设计、编码等，所以通过定义单个需求和特定的产品元素之间的（联系）链，可以从需求向前追溯到下一级工作产品。这种联系链告诉我们每个需求对应的产品部件，从而确保产品部件满足每个需求。

从产品部件回溯到软件需求。说明了每个部件存在的原因。如果不能把设计元素、代码段或测试回溯到一个需求，可能存在“画蛇添足”的程序。然而，如果这些孤立的元素表明了一个正当的功能，则说明需求规格说明书漏掉了一项需求。

4　软件开发的质量与风险
4.1　软件质量管理
 软件质量保证是软件项目控制的重要手段，(23)是软件质量保证的主要活动之一。
2011年(23)
A.风险评估
B.软件评审
C.需求分析
D.架构设计
【答案】B 【解析】本题考查软件质量管理方面的基础知识。

软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动，由质童保证、质量规划和质量控制三个主要活动构成。软件质量保证是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产髙质量的软件。软件评审是软件质量保证的主要活动之一。

4.2　项目风险管理
5　人力资源管理
6　软件的运行与评价
7　软件过程改进
7.1　CMM
 需求管理是CMM可重复级中的6个关键过程域之一，其主要目标是(25)。
2010年(25)
A.对于软件需求，必须建立基线以进行控制，软件计划、产品和活动必须与软件需求保持一致
B.客观地验证需求管理活动符合规定的标准、程序和要求
C.策划软件需求管理的活动，识别和控制已获取的软件需求
D.跟踪软件需求管理的过程、实际结果和执行情况
【答案】A 【解析】 过程能力成熟度模型(Capability Maturity Model,
CMM)在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件过程能力的5个成熟度级别，每一级都包含若干关键过程域(Key Process Areas，KPA)
CMM的第二级为可重复级，它包括了6个关键过程域，分别是：需求管理、软件项目计划、软件项目跟踪和监督、软件分包合同管理、软件质量保证和软件配置管理。
需求管理的目标是为软件需求建立一个基线，提供给软件工程和管理使用：软件计划、产品和活动与软件需求保持一致。
 （24）在软件开发机构中被广泛用来指导软件过程改进。
2016年(24)
A.能力成熟度模型（Capacity Maturity Model）
B.关键过程领域（Key Process Areas）
C.需求跟踪能力链（Traceability Link）
D.工作分解结构（Work Breakdown Structure）
【答案】A
【解析】 CMM即软件开发能力成熟度模型，是用来指导软件过程改进的。

7.2　CMMI
8　软件系统工具
 在实际的项目开发中，人们总是希望使用自动工具来执行需求变更控制过程。下列描述中，(24)不是这类工具所具有的功能。
2010年(24)
A.可以定义变更请求的数据项以及变更请求生存期的状态转换图
B.记录每一种状态变更的数据，确认做出变更的人员
C.可以加强状态转换图使经授权的用户仅能做出所允许的状态变更
D.定义变更控制计划，并指导设计人员按照所制定的计划实施变更
【答案】D 【解析】

对许多项目来说，系统软件总需要不断完善，一些需求的改进是合理的而且不可避免，要使得软件需求完全不变更，也许是不可能的，但毫无控制的变更是项目陷入混乱、不能按进度完成或者软件质量无法保证的主要原因之一。

一个好的变更控制过程，给项目风险承担者提供了正式的建议需求变更机制。可以通过需求变更控制过程来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。

在实际中，人们总是希望使用自动工具来执行变更控制过程。有许多人使用商业问题跟踪工具来收集、存储、管理需求变更；可以使用工具对一系列最近提交的变更建议产生一个列表给变更控制委员会开会时做议程用。问题跟踪工具也可以随时按变更状态分类包裹变更请求的数目。

挑选工具时可以考虑以下几个方面： ①可以定义变更请求的数据项。 ②可以定义变更请求生存期的状态转换图。

③可以加强状态转换图，使经授权的用户仅能做出所允许的状态变更。 ④记录每一种状态变更的数据，确认做出变更的人员。

⑤可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。 ⑥可以根据需要生成标准的或定制的报告和图表。

 在软件系统工具中，版本控制工具属于（29），软件评价工具属于（30）。
2016年(29)
A.软件开发工具
B.软件维护工具
C.编码与排错工具
D.软件管理和软件支持工具
2016年(30)
A.逆向工程工具
B.开发信息库工具
C.编码与排错工具
D.软件管理和软件支持工具
【答案】B D
【解析】 软件系统工具的种类繁多，很难有统一的分类方法。通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。 软件开发工具：需求分析工具、设计工具、编码与排错工具。软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。