D,B ,A。配置状态管理，偏向于配置管理工具
用户文档主要描述所交付系统的功能和使用方法，并不关心这些功能是怎样实现的。
用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。 用户文档至少
应该包括下述 5 方面的内容。
- ①功能描述：说明系统能做什么。
- ②安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。
- ③使用手册：简要说明如何着手使用这个系统(通过丰富的例子说明怎样使用常用的系统功能，并说明用 户操作错误是怎样恢复和重新启动的)。
- ④ 参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出 错信息的含义(对参考手册最主要的要求是完整，因此通常使用形式化的描述技术)。
- ⑤ 操作员指南(如果需要有系统操作员的话):说明操作员应如何处理使用中出现的各种情况。系统文档是从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。
A ,A
这在第十章软件工程中
需求管理的活动包括：
1、变更控制
2、版本控制
3、需求跟踪
4、需求状态跟踪
变更控制委员会可以由一个小组担任，也可以由多个不同的组担任。变更控制委员会的成员应能代表变更涉及的团体。变更控制委员会可能包括如下方面的代表：
(1)产品或计划管理部门；
(2)项目管理部门；
(3)开发部门；
(4)测试或质量保证部门；
(5)市场部或客户代表；
(6)制作用户文档的部门；
(7)技术支持部门；
(8)帮助桌面或用户支持热线部门；
(9)配置管理部门。
A。答案 C。
在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上 准备详细的项目范围说明书，是项目成功的关键。范围定义的输入包括以下内容：
- ①项目章程。如果项目章程或初始 的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。
- ②项目范围管理计划。
- ③ 组织过程资产
- ④批准的变更申请。
C。
配置项是构成产品配置的主要元素，配置项主要有以下两大类：
(1)属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等；
(2)属于项目管理和机构支撑过程域产生的 文档：如工作计划、项目质量报告和项目跟踪报告等。
-- 简单理解是产品过程中的比较倾向于产品组成的是工作成果，比较倾向于管理和过程支撑的就是项目管理和机构支撑过程域
这些文档虽然不是产品的组成部分，但是值得保存。所以设备清单不属于配置项。所以选项C的工作计划虽可充当配置项，但不属于产品组成部分工作成果的配置项。
A
在需求管理过程中需求的变更是受严格管控的，其流程为：
- 1、问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。
- 2、变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析 和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成 并且确认，应该进行是否执行这一变更的决策。
- 3、变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然 后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。
A。答案C。
SCCS是元老级的版本控制软件，也叫 配置 管理软件。
重点题目题
先画图.
正常进度
关键路径：A-C-D-，12。
所以费用 = 10*3+4*12+5*18 = 168 + 5(间接费用) = 173 题目给出的是共需，不是每天的，所以
所需费用 = 10+12+18 = 40 + 5(间接) = 45 也不对，因为它求的是整个工程的费用，并不是B不在关键路径上就不需要费用了，所以
所需费用 = 10+15+12+18 = 55+5(间接) = 60
以上都是正常工期，但是题目问的是完成工程最少的费用，就是让费用最低。
不加班的是55，加班肯定高于55了，正常进度呢是55万+5万=60
要想费用最少，不管加班还是不加班，只要总费用小于等于55就行。如果不加班就是55了，如果加班就是谁的加班费用少就压榨谁，并且，要求加班增加的费用，必须小于省出来的费用，比如D，5天18万，一天就是3.6，最少2天，那么可以省出来3天，3天就可以节省3.6*3=10.8，而加班的费用就是3*2 = 6，所以 节省了10.8，增加了6所以还是节省了。按照这个思路只有
正常一天的费用 加班一天的费用
A：10/3 =3.3 4
B：15/7=2.1 2
C：3 4
D：18/5=3.6 2
可以看出，A、C加班越多，费用越高，因为加班比正常贵啊，B、D越加班越省。
所以B、D加班拉满，
A 10
B 2.1*3 + 2*4
C 12
D 3.6*2+ 3*2
10+8.7+12+10.4+5(间接)=46
天数是12天
要想费用最少，不管加班还是不加班，只要总费用小于等于55就行。如果不加班就是55了，如果加班就是谁的加班费用少就压榨谁，并且，要求加班增加的费用，必须小于省出来的费用
正常一天的费用 加班一天的费用 加班总天数
A：10/3 =3.3 4 1*4
B：15/7=2.1 2 3
C：3 4
D：18/5=3.6 2
这个题没审明白，首先，间接费用是每天5万元，关键路径是12天，而每天的赶工的费用都是低于5万元，所以能赶工都赶工，毕竟一天的间接费用大于赶工的代价。
A最多赶工2天，减少的间接费用是5 *2 =10，增加的赶工费用是 4 * 2 = 8，所以值得赶工。
B最多赶工4天，减少的间接费用是 5 * 4=20，增加的赶工费用是 3 * 2=6
C最多赶工2天，减少的间接费用是 5 * 2 =10，增加的赶工费用是 4 * 2 = 8
C最多赶工3天，减少的间接费用是 5 * 3 =15，增加的赶工费用是 4 * 2 = 8
这样子看都可以赶工，但是前面画的前驱图表示B和C要同时完成，首先A和D必须赶工了，他们没有并行活动，BC要赶工，不能同时赶工，他两个要同时赶工成本是两者之和2+6=6万大于5万不合算，只能赶工其中一个，那么就挑赶工代价最小的赶，赶B(B是2C是4)，ACD是1+4+2=7，而AB是1+7，所以B赶工1天就和ACD同时结束了。
所以最终是A赶工2天，B赶工1天，C不赶工，D赶工3天。
直接费用是：55+ 2*4+ 1*2+ 3*2 =71 ，间接费用是 5 * 7天 = 35，总费用 = 71+35=106，最终天数是7天。（上图中每天增加的费用是赶工一天多付出的费用不是赶工后，用了多少天然后每天增加的费用）。
本题是项目管理中，时间管理的关键路径问题。先将题目中的各个结点依赖关系画出来，
如图所 示：
通过结点依赖图，结合题目正常进度所需天数很容易看出 ACD为关键路径。关键路径长度为12天。但这样得到的就是最短工期与最少花费吗?不是。因为题目指出间接花费是每天5万元，而赶工每天 的费用仅 2-4 万。此时赶工完成部分任务，既能缩短工期，又能降低费用，是合适的解决方案，经过分析，赶工方案为：A赶工2天，B赶工1天，D赶工3天。此时关键路径长度为7天，总花费为106万。
分析过程：主要是看并行的活动，对于单个活动赶工工价<5万，都应该赶工，例如A和D,都
是赶到最少，但是BC是并行的，这两个如果同时赶工，赶工成本就是二者之和，是2+4=6万，因此在BC并行时不能赶工，因为将 AD赶工到最小，ACD长度变成了/7天，而此时AB长度是8天，因此需要将B赶工1天。
106 求法：按照解析的赶工方案，正常进度费用10+15+12+18=55,A赶工2天，2*4=8,B赶工1天，2,D赶工3天，3*2=6,一共55+8+2+6=71,然后间接费用每天5,一共7天是35,最后总的就是71+35=106万元。
B，估算是预计，做计划需要多少钱；预算是分配，要把这个估算分配出去，花出去。
C ，C是对的，A这些属于产品的文档，B配置管理可不是这个意思，配置管理是管理它后面说的那些东西，D操作员指南属于用户文档
配置管理是通过技术和行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。
产品配置是指一个产品在其生命周期各个阶段所产生的各种形式(机器可读或人工可读)和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项(Configuration/Item,CI)，配置项主要有两大类：
- ·属于产品组成部分的工作成果，如需求文档、设计文档、源代码、测试用例等。
- ·属于项目管理和机构支撑过程域产生的文档，如工作计划、项目质量报告、项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。
软件系统的文档可以分为用户文档和系统文档两类。
- 用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；
- 系统文档描述系统设计、实现和测试等各方面的内容。
用户文档是用户了解系统的第一步，它可以让用户获得对系统的准确的初步印象。用户文档至少应该包括下述5方面的内容：
- (1)功能描述：说明系统能做什么;
- (2)安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；
- (3)使用手册：简要说明如何着手使用这个系统(通过丰富的例子说明怎样使用常用系统功能，并说明用户操作错误时怎样恢复和重新启动);
- (4)参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整，因此通常使用形式化的描述技术)
- 5)操作员指南(如果需要有系统操作员的话)：说明操作员应如何处理使用中出现的各种情况。
系统文档 所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。
D、D；B。正确答案：B，D；D
A选项描述的，准确来讲，是产品范围。D选项中的项目范围定义，在整个项目的生命周期中，会有多轮的精化，在进行其它方面分计划制定时，范围是基础。
产品范围(Product Scope)
产品范围指的是 与项目相关的特定产品、服务或成果的功能和特性。在 信息系统项目中，产品范围可以包括软件应用程序的特定 功能、系统的 性能标准、 技术规格和 数据要求等。 产品范围的定义通常包含在 产品需求文档或 系统需求规格(SRS)中。
产品范围的主要内容包括：
- 1.功能性要求：软件或系统必须执行的具体功能，如数据处理、用户管理、报告生成等。
- 2.非功能性要求：系统的性能标准，如响应时间、安全性、可用性等。
- 3.界面要求：系统与其他系统、硬件或软件的交互界面。
- 4.数据管理：数据结构、存储、处理和安全性要求
项目范围(Project Scope)
项目范围指的是 为了做出具有既定功能或特性的最终可交付成果而必须实施的项目工作，包括 技术工作和 管理工作。它 定义了 项目的 边界， 包括项目的 任务、活动、里程碑、资源、预算和时间表。项目范围通常在 项目范围说明书或 项目计划文档中详细描述。
项目范围的主要内容包括：
- 1.工作分解结构(WBS)：将项目工作细分为可管理和可控的小任务。
- 2.里程碑：项目的关键时间点和重要事件。
- 3.资源分配：项目所需的人员、资金、设备和材料。
- 4.风险管理：识别、评估和控制项目风险的计划。
联系与区别
联系：
- 1.产品范围和项目范围都是确保项目成功的关键要素。
- 2.产品范围直接影响项目范围，因为产品的功能和特性需求将决定必须完成哪些工作。
- 3.项目范围的制定和管理是为了确保满足产品范围的要求。
区别：
- 1.定义的焦点不同：产品范围关注的是最终交付的产品或服务的特性和功能，而项目范围关注的是实现这些产品或服务所需的工作。
- 2.变更管理：产品范围的变更通常影响项目的成本和时间线，而项目范围的变更可能不直接影响产品的功能或特性。
- 3.管理过程：产品范围的定义和变更通常需要客户或利益相关者的密切参与，而项目范围的管理更多是项目团队的责任。
- 4、先后顺序不同，先确定产品范围，后确定项目范围。
- 5、产品范围主要由项目发起人和客户确定，项目范围主要由项目经理和项目管理团队确定。
A
A。D。自动维护版本这属于版本控制属于维护工具，需求管理自动维护不同版本不太贴合，B文档自动更新也不太贴合，C判定变更是否实施需要开会讨论的，比如变更控制委员会，不是自动的
在需求管理过程中需求的变更是受严格管控的，其流程为：
- 1、问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。
- 2、变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析 和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成 并且确认，应该进行是否执行这一变更的决策。
- 3、变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然 后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。
D，C，C。答案： D，C，B。
范围定义的输入包括：
- 范围管理计划：范围管理计划是项目管理计划的组成部分，确定了制定、监督和控制项目范围的各种活动。
- 项目章程：项目章程中包含对项目和产品特征的概括性描述，以及项目审批要求。如果执行组织不使用项目章程，则应取得或编制类似的信息，并用做制定详细范围说明书的基础。
- 需求文件：使用需求文件来选择哪些需求将包含在项目中。
- 批准的变更申请。
- 组织过程资产：可能影响定义范围过程的组织过程资产包括(但不限于):
- 用于制定项目范围说明书的政策、程序和模板；
- 以往项目的项目档案；
- 以往阶段或项目的经验教训。
进度管理，其过程：活动定义-->排序-->资源估算-->历时估算-->制定计划-->进度控制
活动定义的常用工具包括：
1.分解
采用分解技术来定义活动，就是要把项目工作包分解成更小的、更易于管理的组成部分，即活动——为完成工作包而必须开展的工作。定义活动过程最终输出的是活动，而非可交付成果。可交付成果是创建工作分解结构过程的输出。
WBS、WBS 词典与活动清单，既可依次编制，也可同时编制。WBS和 WBS 词典是制定最终活动清单的依据。WBS 中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果。让团队 WBS 成员参与分解，有助于得到更好、更准确的结果。
2.滚动式规划
滚动式规划是一种渐进明细的规划方式，即对近期要完成的工作进行详细规划，而对远期工作则暂 时只在WBS 的较高层次上进行粗略规划。因此，在项目生命周期的不同阶段，工作分解 WBS 的详细程度会有所不同。例如，在早期的战略规划阶段，信息尚不够明确，工作包也许只能分解到里程碑的水平；而后，随着了解到更多的信息，近期即将实施的工作包就可以分解成具体的活动。
3.模板
标准活动清单或以往项目的部分活动清单，经常可用做新项目的模板。模板中的活动属性信息，也 有助于定义活动。模板还可用来识别典型的进度里程碑。
4.专家判断
富有经验并擅长制定详细项目范围说明书、工作分解结构和项目进度计划的项目团队成员或其他专 家，可以为定义活动提供专业知识。
“对系统开发的各种候选方案进行成本/效益分析”和“评价该项目实施后可能取得的无形收益”是 从成本效益的角度来看一个项目的可行性，是从经济角度出发的分析，这属于可行性分析的范畴。而“评估现有技术能力和信息技术是否足以支持系统目标的实现”是典型的技术可行性分析。“分析现有系统存在的运行问题”与可行性分析无直接关系。
