title: 软件项目管理题分析
date: 2025-06-14T16:46:19Z
lastmod: 2025-06-14T18:54:15Z
软件项目管理题分析
软件项目管理题分析
第一章
二、判断题分析
判断题的关键是理解项目管理的核心概念(如临时性、独特性、资源约束)。每个题目我会先给出正确选项,再解释原因。
- 搬家属于项目。(√)
正确(√)
原因:项目是临时性的、独特的努力,有明确的目标、起点和终点。搬家是一次性活动,有具体目标(如“在一天内将所有物品搬到新地址”),符合项目的定义。日常运作(如每天打扫房间)是重复性的,而搬家不是。 - 项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的永久性的努力。(×)
错误(×)
原因:项目是临时性的(有明确开始和结束),不是永久性的。永久性努力属于日常运作(如持续维护软件)。项目的核心是“临时性”和“独特性”,例如开发一个新软件是项目,但后续维护是日常运作。 - 过程管理就是对过程进行管理,目的是要让过程能够被共享、复用,并得到持续的改进。(√)
正确(√)
原因:过程管理(如软件工程中的CMMI或ISO标准)的核心是标准化、优化过程,使其可共享(跨团队使用)、可复用(减少重复工作),并通过PDCA(Plan-Do-Check-Act)循环持续改进。这在项目管理中很常见,例如敏捷开发中的迭代回顾。 - 项目具有临时性的特征。(√)
正确(√)
原因:临时性是项目的三大特征之一(其他是独特性和渐进明细)。项目必须有明确的起点(如立项)和终点(如交付成果),而日常运作是持续性的。例如,开发一个APP是临时项目,但APP上线后的用户支持是日常运作。 - 日常运作存在大量的变更管理,而项目基本保持连贯性的。(×)
错误(×)
原因:实际情况相反。项目由于临时性和独特性(如需求不确定),经常需要变更管理(如需求变更、风险应对)。日常运作更稳定,变更较少(如流水线生产)。项目管理的重点之一就是处理变更(如变更控制流程)。 - 项目开发过程中可以无限制地使用资源。(×)
错误(×)
原因:项目受资源约束(时间、成本、人力),这是项目管理的“三重约束”之一。资源有限性要求项目经理优化分配(如资源平衡技术)。无限制使用资源会导致成本超支或失败,例如软件开发中不能无限添加程序员。 - 相比传统开发的预测性过程,敏捷开发属于自适应过程(√)
正确(√)
原因:传统开发(如瀑布模型)是预测性的——提前计划所有细节并严格执行。敏捷开发(如Scrum)是自适应的——通过迭代(sprint)响应变化,强调灵活调整。这是敏捷的核心原则,适应需求变更而非遵循固定计划。
三、选择题分析
选择题的关键是区分项目与日常运作、理解PMBOK知识域、敏捷宣言等。每个题目我会分析选项,给出正确答案,并解释原因(包括为什么其他选项错误)。
下列选项中不是项目与日常运作的区别的是(C)
- 选项:
A. 项目是以目标为导向的,日常运作是通过效率和有效性体现的。
B. 项目是通过项目经理及其团队工作完成的,而日常运作是职能式的线性管理。
C. 项目需要有专业知识的人来完成,而日常运作的完成无需特定专业知识。
D. 项目是一次性的,日常运作是重复性的。
正确答案:C
原因: - A、B、D 正确描述了区别:项目目标导向、临时性、团队驱动;日常运作效率导向、重复性、职能管理。
- C 错误:日常运作同样需要专业知识(如财务人员做账),这不是关键区别。关键区别是临时性 vs. 重复性,而非专业知识。
复习点:项目与日常运作的核心区别是临时性、独特性和成果导向。
- 选项:
以下都是日常运作和项目的共同之处,除了(D)
- 选项:
A. 由人来做
B. 受限于有限的资源
C. 需要规划、执行和控制
D. 都是重复性工作
正确答案:D
原因: - A、B、C 是共同点:都需要人力资源;都受资源限制(时间、预算);都需要管理过程(如计划、监控)。
- D 不是共同点:项目是独特、一次性的(如开发新系统),日常运作是重复性的(如每月工资发放)。项目不重复。
复习点:项目本质是临时性努力,日常运作是持续性活动。
- 选项:
下面选项中不是PMBOK的知识域的是(A)
- 选项:
A. 招聘管理
B. 质量管理
C. 范围管理
D. 风险管理
正确答案:A
原因: - PMBOK指南第7版有10大知识领域:整合、范围、进度、成本、质量、资源、沟通、风险、采购、相关方管理。
- B(质量管理)、C(范围管理)、D(风险管理)都是标准知识域。
- A 错误:招聘管理是资源管理知识域的一部分,但不是独立知识域。PMBOK没有“招聘管理”这一分类。
复习点:PMBOK知识域是项目管理的基础框架,需熟记核心领域。
- 选项:
下列选项中属于项目的是(C)
- 选项:
A. 上课
B. 社区保安
C. 野餐活动
D. 每天的卫生保洁
正确答案:C
原因: - 项目是临时性、独特的活动:野餐活动是一次性事件(如“周末公司团建”),有明确目标、起点和终点。
- A、B、D 是日常运作:上课是重复性教学;社区保安是持续性服务;卫生保洁是例行维护。这些没有项目特征。
复习点:判断项目标准:是否临时、独特、有交付物。
- 选项:
下列选项中正确的是(C)
- 选项:
A. 一个项目具有明确的目标而且周期不限
B. 一个项目一旦确定就不会发生变更
C. 每个项目都有自己的独特性
D. 项目都是一次性的并由项目经理独自完成
正确答案:C
原因: - C 正确:独特性是项目核心特征(如每个软件开发项目需求不同)。
- A 错误:项目周期必须有限(临时性),不能“不限”。
- B 错误:项目常发生变更(如需求变化),需变更管理流程。
- D 错误:项目由团队完成,不是项目经理独自承担(如敏捷团队协作)。
复习点:项目三大特征:临时性、独特性、渐进明细。
- 选项:
(B)是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。
- 选项:
A. 过程
B. 项目
C. 项目群
D. 组合
正确答案:B
原因: - 这是项目的标准定义(PMBOK)。项目针对独特成果(如新软件),且临时性。
- A 错误:过程是持续活动(如开发流程),不一定是临时性。
- C 错误:项目群是相关项目的集合(如多个产品线开发)。
- D 错误:组合是组织级项目/项目群集合(如投资组合)。
复习点:项目定义是基础,区分项目、项目群和组合。
- 选项:
下面选项中不是《敏捷宣言》中的内容的是(C)
- 选项:
A. 个体和交互胜过过程和工具
B. 可以工作的软件胜过面面俱到的文档
C. 敏捷开发过程是自适应的过程
D. 响应变化胜过遵循计划
正确答案:C
原因: - 敏捷宣言只有4个价值观:A、B、D是原文(加上“客户合作胜过合同谈判”)。
- C 错误:虽然自适应是敏捷特点,但这不是宣言中的内容;它是对敏捷的描述,而非核心价值。
复习点:敏捷宣言必须原文记忆:4个价值观,12条原则。
- 选项:
下列活动中不是项目的是(C)
- 选项:
A. 野餐活动
B. 集体婚礼
C. 上课
D. 开发操作系统
正确答案:C
原因: - A、B、D 是项目:野餐活动(一次性事件)、集体婚礼(独特活动)、开发操作系统(临时性、独特产品)。
- C 错误:上课是日常运作(重复性教学,如每周课程),除非是“设计一门新课”才属于项目。
复习点:日常运作是重复、常规活动;项目是打破常规的努力。
- 选项:
下列选项中不是项目的特征的是(C)
- 选项:
A. 项目具有明确的目标
B. 项目具有限定的周期
C. 项目可以重复进行
D. 项目对资源成本具有约束性
正确答案:C
原因: - A、B、D 是项目特征:目标导向(SMART原则)、临时性(限定周期)、资源约束(三重约束)。
- C 错误:项目是独特的,不能重复(如每个软件开发项目都不同);重复性是日常运作的特征。
复习点:项目特征:临时性、独特性、约束性(范围、时间、成本)。
- 选项:
复习建议
- 核心概念重点:项目定义(临时性、独特性)、项目 vs. 日常运作、PMBOK知识域、敏捷宣言是高频考点。判断题多考特征,选择题多考区别。
- 突击技巧:用例子记忆(如“搬家是项目,保洁是日常运作”),避免死记硬背。
- 易错点:变更管理(项目变更多)、资源约束(项目资源有限)、敏捷自适应(vs. 传统预测性)。
如果您有更多题目或需要进一步解释,随时告诉我!祝期末顺利!
第二章
二、判断题分析
- 项目立项可以确立项目目标、时间和资源成本,同时得到项目发起人的认可。(√)
正确(√)
原因:立项是项目启动的核心环节,需明确目标、时间、成本基线,并需发起人正式批准(如签署项目章程)。这是项目合法性的基础。 - 项目招标对于一个项目的开发是必需的,即便项目是内部项目。(×)
错误(×)
原因:内部项目可由团队直接承接,无需招标(如公司自主研发系统)。招标仅适用于需外部供应商参与的场景(如外包开发),非强制流程。 - make or buy决策中的make指的只是自主开发。(√)
正确(√)
原因:”Make“指内部自主完成(开发/生产),”Buy“指外部采购。例如,开发团队选择自研功能模块而非购买插件。 - 项目建议书是项目计划阶段开发的文档。(×)
错误(×)
原因:项目建议书在初始阶段(启动前)编写,用于论证项目可行性并申请立项。计划阶段输出的是WBS、进度计划等执行文档。 - 项目立项需要获得项目经理的认可,但不需要项目发起人的认可。(×)
错误(×)
原因:立项的核心是发起人授权(批准章程、提供资源)。项目经理可能在立项后任命,其认可非必需流程。 - 项目章程是项目执行组织高层批准的确认项目存在的文件,其中不包括对项目经理的授权。(×)
错误(×)
原因:项目章程必须明确项目经理的权责(如资源调配权、决策权),这是PMBOK的核心要求。无授权则项目经理无法有效管理。 - 乙方即供方(有时也称卖方)是为顾客提供产品或服务的一方。(√)
正确(√)
原因:合同关系中,甲方(客户)提出需求,乙方(供应商)交付成果(如软件公司为客户开发系统)。 - 在软件项目合同中,甲方是需求方,乙方是供方。(√)
正确(√)
原因:甲方是委托方(支付费用),乙方是承接方(提供开发服务),符合商业合同惯例。 - 敏捷项目采取的是仆人式管理方式(√)
正确(√)
原因:仆人式领导(Servant Leadership)是敏捷管理的核心:项目经理服务于团队,移除障碍、赋能成员(而非命令控制),促进自组织。
三、选择题分析
下列不是项目立项过程内容的是(B)
- 选项:
A.项目的目标
B.项目的风险
C.项目的时间表
D.项目使用的资源和经费
正确答案:B
原因: - 立项聚焦目标、时间、资源等基线(A、C、D)。
- 风险分析属于计划阶段(如制定风险登记册),立项时仅初步识别,非核心内容。
- 选项:
以下哪项不包括在项目章程中?(C)
- 选项:
A.对项目的确认
B.对项目经理的授权
C.对项目风险的分析
D.项目目标的描述
正确答案:C
原因: - 项目章程内容(PMBOK标准):目标、项目经理授权、高层级需求、总体里程碑。
- 风险分析在计划阶段深入进行,章程仅包含高层级假设/约束。
- 选项:
项目建议书是(C)阶段开发的文档
- 选项:
A.项目执行
B.项目结尾
C.项目初始
D.项目计划
正确答案:C
原因: - 项目建议书在初始阶段(启动前)编写,用于论证可行性并申请立项,通过后进入正式启动。
- 选项:
下列不属于甲方招投标阶段任务的是?(A)
- 选项:
A.编写建议书
B.招标书定义
C.供方选择
D.合同签署
正确答案:A
原因: - 甲方任务:定义需求(B)、评估投标(C)、签约(D)。
- 编写建议书是乙方任务(响应招标)。
- 选项:
下列不属于乙方招投标阶段任务的是?(D)
- 选项:
A.项目分析
B.竞标
C.合同签署
D.招标书定义
正确答案:D
原因: - 乙方任务:分析招标要求(A)、提交提案(B)、签约(C)。
- 招标书定义是甲方职责(乙方无权定义)。
- 选项:
PMI人才三角不包括(B)
- 选项:
A.技术项目管理
B.测试能力
C.领导力
D.战略和商务管理
正确答案:B
原因: - PMI人才三角三大维度:技术项目管理(A)、领导力(C)、战略与商务管理(D)。
- 测试能力属于技术细节,非战略级能力框架。
- 选项:
易混淆点总结
概念 | 关键辨析 |
---|---|
立项 vs 计划 | 立项:目标/时间/资源基线(章程);计划:详细范围/进度/风险(项目管理计划) |
招标必要性 | 仅需外部供应商时招标;内部项目可直委团队 |
Make or Buy | Make=自主完成;Buy=外包采购(含购买现成产品/服务) |
仆人式管理 | 敏捷特色:项目经理服务团队(非命令控制),聚焦赋能、移除障碍 |
甲方/乙方角色 | 甲方=需求方/出资方;乙方=供应方/执行方(合同关系核心) |
💡 突击技巧:
- 记立项与计划阶段文档差异:建议书→章程→项目管理计划。
- 选择题优先排除与阶段不符的选项(如风险分析不在章程中)。
- 判断题紧扣定义(如“招标非必需”“仆人式管理=服务团队”)。
第三章
二、判断题分析
- 瀑布模型不适合短期项目。(×)
错误(×)
原因:瀑布模型适用于需求明确、规模小、周期短的项目(如简单功能开发)。短期项目若需求固定,瀑布模型的线性流程反而高效。真正不适合的是需求频繁变更的长期项目。 - 增量式模型可以避免一次性投资太多带来的风险。(√)
正确(√)
原因:增量式模型分阶段交付部分功能,客户可分期投资(如先支付核心模块费用)。若早期增量失败,可及时止损,降低整体财务风险。 - V模型适合需求很明确、解决方案很明确,且对系统性能要求严格的项目。(√)
正确(√)
原因:V模型强调测试与开发的严格对应(如需求→验收测试、设计→系统测试),适合需求固定、质量要求高的场景(如航天、医疗软件)。 - 瀑布模型和V模型都属于预测型生存期模型(√)
正确(√)
原因:预测型模型需在项目初期完全定义需求和计划。瀑布模型(阶段线性推进)和V模型(测试驱动开发)均属此类,无法灵活响应变更。 - 在瀑布模型中,活动严格按顺序执行,一个阶段的输出是下一个阶段的输入。(√)
正确(√)
原因:瀑布模型的核心是阶段间强顺序依赖(如需求分析→设计→编码→测试)。前一阶段文档(输出)是后一阶段的基础(输入),不可并行。 - 极限编程从3个层面提供了13个敏捷实践(√)
正确(√)
原因:XP(极限编程)的13个实践分为三个层面:团队协作(如结对编程)、技术实践(如测试驱动开发)、项目管理(如小版本发布)。 - 敏捷包括《敏捷宣言》的价值观、12个原则及通用实践(❌)
正确(√)
原因:敏捷框架由4大价值观(如“响应变化胜过遵循计划”)、12原则(如“欢迎需求变更”)及具体实践(如Scrum、XP)构成。
三、选择题分析
甲方提供详细需求,解决方案明确,安全性严格,适合的模型是(C)
- 选项:A.瀑布模型 B.增量式模型 C.V模型 D.XP模型
正确答案:C
原因: - V模型的高强度测试(如安全测试)和严格阶段对应,特别适合安全关键系统。
- 瀑布模型虽需求明确,但测试强度不足;XP模型(敏捷)无法满足严格的前期规划需求。
- 选项:A.瀑布模型 B.增量式模型 C.V模型 D.XP模型
属于预测型生存期模型的是(A)
- 选项:A.瀑布模型 B.增量型模型 C.Scrum模型 D.原型模型
正确答案:A
原因: - 预测型模型需预先规划全部需求。瀑布模型是典型代表。
- B/C/D均为迭代或适应型模型:增量式分阶段交付、Scrum属敏捷、原型模型需反复验证需求。
- 选项:A.瀑布模型 B.增量型模型 C.Scrum模型 D.原型模型
关于敏捷模型描述不正确的是(D)
- 选项:A.敏捷是自适应过程 B.可应对需求变化 C.Scrum/XP/DevOps属敏捷 D.敏捷是预测型和迭代型的混合
正确答案:D
原因: - 敏捷本质是自适应过程(响应变化),与预测型(预先计划)对立。混合模型(如增量式)才是预测+迭代的结合。
- 选项:A.敏捷是自适应过程 B.可应对需求变化 C.Scrum/XP/DevOps属敏捷 D.敏捷是预测型和迭代型的混合
XP模型的实践原则不包括(D)
- 选项:A.快速反馈 B.假设简单 C.包容变化 D.详细设计
正确答案:D
原因: - XP提倡简单设计(YAGNI原则:不做过度设计),通过迭代优化。详细设计是瀑布模型的特点。
- 选项:A.快速反馈 B.假设简单 C.包容变化 D.详细设计
需求不明确时应避免的模型是(C)
- 选项:A.快速原型模型 B.增量式模型 C.V模型 D.Scrum模型
正确答案:C
原因: - V模型需完全明确需求才能设计测试用例。需求不明时,应选迭代模型(如原型模型探索需求、Scrum拥抱变更)。
- 选项:A.快速原型模型 B.增量式模型 C.V模型 D.Scrum模型
关于迭代模型说法不正确的是(D)
- 选项:A.不断反馈原型 B.加快开发速度 C.需求变化大 D.不多次提交
正确答案:D
原因: - 迭代模型核心是多次提交可运行版本(如每2周交付增量)。选项D直接违背迭代本质。
- 选项:A.不断反馈原型 B.加快开发速度 C.需求变化大 D.不多次提交
核心概念对比表
模型类型 | 特点 | 适用场景 | 禁用场景 |
---|---|---|---|
瀑布模型 | 线性顺序、阶段严格、文档驱动 | 需求明确、变更少的短期小项目 | 需求模糊、高风险项目 |
V模型 | 测试驱动、开发与测试严格对应 | 安全/质量要求高的固定需求项目 | 需求易变、探索性项目 |
增量模型 | 分阶段交付功能、降低投资风险 | 可模块化系统、客户需早期部分功能 | 架构不可分割的系统 |
敏捷模型 | 自适应、迭代交付、拥抱变化(Scrum/XP) | 需求不明确、变更频繁的项目 | 法规要求严格的前期文档项目 |
极限编程(XP) | 技术实践为核心(TDD、结对编程)、快速反馈 | 小型团队、高质量要求的快速开发 | 大型团队、固定流程组织 |
💡 突击技巧:
- 判断模型适用性:需求明确度 > 项目规模 > 质量要求。
选择题排除法:
- 需求不明时排除预测型(瀑布/V模型)
- 质量严格时排除纯敏捷(选V模型或增量式)
判断题抓关键词:
- “严格顺序”→瀑布模型
- “测试驱动”→V模型
- “分阶段交付”→增量模型
第四章
二、判断题分析
- 需求规格说明可以包括系统的运行环境。(√)
正确:需求规格说明书(SRS)需明确硬件、操作系统、网络环境等运行约束条件(如“系统需在Windows Server 2016+运行”)。 - 数据流分析方法是一种自下而上逐步求精的分析方法。(×)
错误:数据流分析(DFD)是自上而下的分解过程(从顶层上下文图逐层细化到过程细节),非自下而上。 - 需求分析完成的标志是形成完整规范的需求规格说明书。(✅)
错误:现代需求工程强调持续验证与更新。完成标志是需求通过正式评审+客户签字确认(SRS仅是输出物,可能需迭代更新)。 - 需求是用户对软件功能、性能的要求。(√)
正确:需求本质是用户期望的功能(做什么) 与性能(响应速度、并发能力等) 的集合。 - 用户故事常写在卡片上并部署在墙上。(√)
正确:敏捷项目中,用户故事(User Story)以卡片形式展示在任务墙(如Kanban板),便于可视化跟踪。 - 系统的响应时间属于功能性需求。(×)
错误:响应时间是非功能性需求(性能指标)。功能性需求描述系统行为(如“支持用户登录”),非功能性需求描述系统属性(如“登录响应时间≤2秒”)。 - 数据字典由数据项、数据流及操作指令组成。(×)
错误:数据字典(DD)核心组成:数据项、数据结构、数据流、数据存储。操作指令属于处理逻辑,在过程规格中定义(如结构化语言)。
三、选择题分析
不属于需求过程的是?(D)
- 选项:A.需求获取 B.需求分析 C.需求规格编写 D.需求更新
答案:D
原因:需求过程三核心:获取→分析→规格化。更新属于需求维护,是项目执行中的持续活动。
- 选项:A.需求获取 B.需求分析 C.需求规格编写 D.需求更新
不属于数据字典组成部分的是?(D)
- 选项:A.数据项 B.数据流 C.数据文件 D.数据库
答案:D
原因:数据字典定义数据元素(A)、流动路径(B)、存储文件(C)。数据库是物理存储实体,非DD描述对象。
- 选项:A.数据项 B.数据流 C.数据文件 D.数据库
不属于UML需求视图的是?(A)
- 选项:A.甘特图 B.用例图 C.状态图 D.顺序图
答案:A
原因:UML需求视图包括用例图(功能)、状态图(行为)、顺序图(交互)。甘特图是进度管理工具(非UML标准)。
- 选项:A.甘特图 B.用例图 C.状态图 D.顺序图
关于用户故事描述不正确的是(D)
- 选项:A.英文名user story B.非技术语言描述 C.描述敏捷需求 D.一种数据结构
答案:D
原因:用户故事是需求描述格式(如“作为用户,我希望...”),非数据结构。其核心是用户视角的简短叙述。
- 选项:A.英文名user story B.非技术语言描述 C.描述敏捷需求 D.一种数据结构
导致软件项目蔓延的特点是?(A)
- 选项:A.需求变更 B.暂时性 C.阶段性 D.约束性
答案:A
原因:需求变更是范围蔓延(Scope Creep)的主因(如新增未计划功能),直接导致项目延期/超支。
- 选项:A.需求变更 B.暂时性 C.阶段性 D.约束性
不属于结构化方法设计的是?(D)
- 选项:A.数据流图(DFD) B.数据字典(DD) C.系统流程图 D.系统用例图
答案:D
原因:结构化方法使用DFD、DD、流程图(B、C)。用例图是面向对象方法(如UML)的需求工具。
- 选项:A.数据流图(DFD) B.数据字典(DD) C.系统流程图 D.系统用例图
不属于软件需求范畴的是?(A)
- 选项:A.采用何种实现技术 B.用户期望的功能 C.软件性能要求 D.用户业务目标
答案:A
原因:需求关注 “做什么”(What) ,技术选型(如Java/Python)属于解决方案(“怎么做”),是设计阶段决策。
- 选项:A.采用何种实现技术 B.用户期望的功能 C.软件性能要求 D.用户业务目标
敏捷需求描述常用形式是(C)
- 选项:A.用户用例 B.DFD C.用户故事 D.数据字典
答案:C
原因:敏捷项目以用户故事(User Story) 作为核心需求载体(如“作为会员,我想搜索商品以便快速购买”),取代传统SRS。
- 选项:A.用户用例 B.DFD C.用户故事 D.数据字典
核心概念速记表
关键点 | 易混淆项辨析 |
---|---|
需求规格说明书(SRS) | 必须包含功能需求、非功能需求(性能/安全)及运行环境(判断题1) |
数据流分析(DFD) | 自上而下分解(判断题2×) → 顶层图/0层图/细节图 |
需求完成标志 | 客户正式签字确认(非文档完成!),贯穿项目生命周期(判断题3×) |
功能性 vs 非功能性 | 功能需求:系统行为(如“生成报表”);非功能需求:性能/安全/兼容性(如“报表加载时间≤3秒”,判断题6×) |
用户故事本质 | 用户视角的需求描述(非技术语言/非数据结构),用于敏捷协作(选择题4D×,8C√) |
结构化分析方法 | 工具:DFD + 数据字典 + 流程图(不包含UML图!选择题6D√) |
需求 vs 设计 | 需求=做什么(业务目标);设计=怎么做(技术实现) → 技术选型不属于需求(选择题7A√) |
💡 突击技巧:
- 判断题抓反常识点:如“需求完成=文档完成”(×)、“响应时间=功能性”(×)。
选择题用排除法:
- 数据库≠数据字典(选D)
- 甘特图≠UML(选A)
- 技术实现≠需求(选A)
- 重点区分结构化(DFD/DD) 与 面向对象(UML用例图) 方法!
第五章
二、判断题分析
- WBS提供了项目范围基线。(√)
正确:WBS是范围基准的核心组件,明确项目边界(包含/不包含的工作),是范围控制的基础。 - 一个工作包可以分配给另一个项目经理完成。(√)
正确:工作包(Work Package)是WBS最底层的可交付成果,可分配给子项目经理或特定团队独立完成。 - 熟悉项目时,开发WBS最好用自底向上方法。(×)
错误:对熟悉项目应采用自顶向下(从整体到细节),效率更高;自底向上适合陌生项目(先列细节再归纳)。 - 没有做过的项目,可用自底向上方法开发WBS。(√)
正确:全新项目通过自底向上(先脑暴所有任务,再分层归纳)避免遗漏细节,适合探索性工作。 WBS最底层要素必须是实现目标的充分必要条件。(√)
正确:最底层任务(工作包)需满足两个条件:- 充分性:全部完成即可实现上层交付物;
- 必要性:缺一不可。
- 一个工作包应由唯一主题负责。(√)
正确:工作包需遵循 “责任单一化” 原则(通常对应一个责任人/团队),避免职责不清。 - WBS最高层可交付成果是工作包。(×)
错误:WBS层级关系为:项目→可交付成果→工作包→活动。最高层是项目整体,工作包是最底层。 - 任务分解只能是自上而下。(×)
错误:分解方法包括自顶向下(主流)和自底向上(特殊场景),见判断题3、4。 - WBS最底层任务是能分配到一个人完成的任务。(√)
正确:最底层任务(工作包)应可分配给单人或单一团队,确保责任明确且可管理。 - Epic可继续分解为用户故事。(√)
正确:敏捷中,Epic(大型需求)→ 用户故事(独立功能)→ 任务,是WBS的敏捷实践形式。
三、选择题分析
WBS作用不包括(D)
- 选项:A.组织工作 B.防遗漏 C.估算依据 D.确定成员责任
答案:D
原因:WBS定义工作范围,责任分配需依赖责任分配矩阵(RAM) (如RACI图)。
- 选项:A.组织工作 B.防遗漏 C.估算依据 D.确定成员责任
WBS细目通常指定唯一(A)
- 选项:A.编码 B.地点 C.功能模块 D.截止期限
答案:A
原因:WBS编码(如1.1.2)是唯一标识,用于跟踪成本和进度,与组织无关。
- 选项:A.编码 B.地点 C.功能模块 D.截止期限
不是创建WBS方法的是(C)
- 选项:A.自顶向下 B.自底向上 C.控制方法 D.模板参照
答案:C
原因:WBS开发方法仅包括自顶向下/自底向上/类比参照/模板复用,无“控制方法”。
- 选项:A.自顶向下 B.自底向上 C.控制方法 D.模板参照
从特殊到一般的分解方法是(D)
- 选项:A.模板参照 B.自顶向下 C.类比 D.自底向上
答案:D
原因:自底向上先定义细节任务,再聚类为高层交付物(特殊→一般)。
- 选项:A.模板参照 B.自顶向下 C.类比 D.自底向上
关于WBS说法不正确的是(D)
- 选项:A.WBS是分解结果 B.非WBS内非项目工作 C.可图表/清单表示 D.崭新项目用自顶向下
答案:D
原因:崭新项目不确定性高,应选自底向上(见判断题4);自顶向下适合熟悉项目。
- 选项:A.WBS是分解结果 B.非WBS内非项目工作 C.可图表/清单表示 D.崭新项目用自顶向下
检验WBS标准不包括(B)
- 选项:A.底层要素充分必要 B.层次≥3层 C.底层无重复 D.要素明确定义
答案:B
原因:WBS层级数取决于项目复杂度(简单项目可能只有2层),非固定要求。
- 选项:A.底层要素充分必要 B.层次≥3层 C.底层无重复 D.要素明确定义
WBS结构是(B)
- 选项:A.分层的集合结构 B.分级的树形结构 C.分层的线性结构 D.分级的图状结构
答案:B
原因:WBS本质是树形结构(父子层级),根节点是项目,叶节点是工作包。
- 选项:A.分层的集合结构 B.分级的树形结构 C.分层的线性结构 D.分级的图状结构
从一般到特殊的分解方法是(B)
- 选项:A.模板参照 B.自顶向下 C.类比 D.自底向上
答案:B
原因:自顶向下从项目整体(一般)逐层分解到工作包(特殊)。
- 选项:A.模板参照 B.自顶向下 C.类比 D.自底向上
核心概念对比表
关键点 | 易错辨析 | 记忆技巧 |
---|---|---|
WBS本质 | 范围基准(非进度/成本基准) → 判断题1√ | WBS是“工作”分解,非责任分解(选择题1D√) |
分解方法选择 | - 熟悉项目→自顶向下 - 陌生项目→自底向上 → 判断题3×、4√,选择题5D× | “上熟下生” |
工作包特性 | - 最底层 - 可分配单人/团队 - 责任唯一 → 判断题6√、7×、9√ | 工作包=叶节点(树形结构底层) |
敏捷WBS | Epic→用户故事→任务(判断题10√) → 本质仍是层级分解 | 用户故事≈工作包 |
WBS检验标准 | - 底层要素充分必要(判断题5√) - 无重复(选择题6C) - 明确定义(选择题6D) | 排除“层次≥3层”(选择题6B×) |
💡 突击技巧:
- 判断题抓绝对词:如“只能自上而下”(×,见判断题8×)、“最高层是工作包”(×,见判断题7×)。
选择题用关键词匹配:
- “特殊→一般”→自底向上(选择题4D)
- “一般→特殊”→自顶向下(选择题8B)
重点区分:
- WBS(范围) vs RAM(责任)
- 工作包(底层交付物) vs 活动(进一步分解的动作)
第六张
二、判断题分析
- 故事点估算是相对的估算过程。(√)
正确:故事点表示相对复杂度(如任务A是B的2倍难),而非绝对时间,便于跨团队比较。 - 软件项目估算结果没有误差。(×)
错误:估算是概率预测,受需求变更、技术风险等影响必有误差(如±20%)。追求“准确”而非“精确”。 - 人力消耗是软件主要成本。(√)
正确:软件成本中人力成本占比70-80% (开发者工资、培训等),远超硬件或工具成本。 - 功能点估算与技术语言有关。(×)
错误:功能点(FP)基于用户视角的功能计数(如输入/输出数),与实现语言无关。代码行(LOC)才与技术相关。 - COCOMO81模型分有机型、嵌入型、半嵌入型。(×)
错误:COCOMO81三模型为:有机型(简单)、半分离型(中等)、嵌入型(复杂) ,无“半嵌入型”。 - 经验对估算不重要。(×)
错误:专家经验是类比估算基础。缺乏历史数据时,经验是核心依据(尤其早期估算)。 估算需考虑直接+间接成本。(√)
正确:- 直接成本:项目专属(如开发人员工资)
- 间接成本:分摊成本(如办公室租金、水电) → 总成本=直接+间接
- 可直接套用其他企业模型估算。(×)
错误:估算模型(如COCOMO)需校准(调整参数适配组织能力)。直接套用忽略团队差异,导致偏差。 - 间接成本与具体项目相关。(×)
错误:间接成本是组织公共开销(如管理层工资),需分摊到多个项目,非专属单一项目。
三、选择题分析
三点估算法不包括(D)
- 选项:A.最可能成本 B.最乐观成本 C.最悲观成本 D.项目经理估算值
答案:D
原因:三点估算公式为(乐观+4×最可能+悲观)/6
,无需项目经理主观估值。
- 选项:A.最可能成本 B.最乐观成本 C.最悲观成本 D.项目经理估算值
关于估算的错误说法(C)
- 选项:A.估算有误差 B.勿迷信模型 C.经验不重要 D.历史数据重要
答案:C
原因:经验是类比估算核心(尤其缺乏数据时)。反例:专家判断法依赖经验。
- 选项:A.估算有误差 B.勿迷信模型 C.经验不重要 D.历史数据重要
成绩录入功能的故事点(A)
- 注册功能=3点,成绩录入略多 → Fibonacci等级:3下一级为5(1,2,3,5,8...)
答案:A.5个故事点
关键:Fibonacci序列禁止插值(略多则跳至5,不能选4)。
- 注册功能=3点,成绩录入略多 → Fibonacci等级:3下一级为5(1,2,3,5,8...)
成本估算的基础是(B)
- 选项:A.计划 B.规模 C.风险 D.利润
答案:B
原因:规模(如代码行、功能点)是成本驱动主因 →成本 = f(规模)
。
- 选项:A.计划 B.规模 C.风险 D.利润
非常见成本估算方法(D)
- 选项:A.代码行 B.功能点 C.类比法 D.关键路径法
答案:D
原因:关键路径法是进度管理技术,非成本估算方法(成本估算常用:参数法、类比法、三点法)。
- 选项:A.代码行 B.功能点 C.类比法 D.关键路径法
非UFC功能计数项(C)
- UFC标准计数项:外部输入、输出、查询、外部接口文件、内部文件
答案:C.内部输出(无此分类)
辨析: - 外部输出:系统向用户发送数据(如报表)
- 内部文件:系统内部存储数据(如数据库表)
- UFC标准计数项:外部输入、输出、查询、外部接口文件、内部文件
成本预算目的(A)
- 选项:A.生产成本基线 B.编写报告 C.指导设计 D.进度管理
答案:A
原因:成本预算核心输出是成本绩效基线(S曲线),用于后续成本控制。
- 选项:A.生产成本基线 B.编写报告 C.指导设计 D.进度管理
非软件规模单位(D)
- 选项:A.LOC B.FP C.人月/人年 D.小时
答案:D
原因:规模单位描述工作总量(如LOC、FP),小时是时间单位,需通过生产率转换(如FP/人天)。
- 选项:A.LOC B.FP C.人月/人年 D.小时
时间段内各工作单元成本是(B)
- 选项:A.估算 B.预算 C.直接成本 D.间接成本
答案:B
原因:预算是时间分配后的成本计划(如每月10万元)。估算在预算前,确定总成本范围。
- 选项:A.估算 B.预算 C.直接成本 D.间接成本
核心概念速记表
关键点 | 易错辨析 | 实例 |
---|---|---|
故事点本质 | 相对估算(无单位) → 基于团队速度(Velocity)换算时间(判断题1√) | Fibonacci序列:3的下一个是5(选择题3A√) |
功能点优势 | 与技术无关(判断题4×) → 适合早期估算(选择题5B) | UFC计数项:外部输入/输出/文件(选择题6C×) |
成本构成 | 总成本 = 直接成本(专属项目) + 间接成本(组织分摊)(判断题7√,9×) | 人力成本占比最高(判断题3√) |
估算误差必然性 | 所有估算均有误差 → 需预留应急储备(判断题2×) | 三点估算法量化不确定性(选择题1D×) |
规模驱动成本 | 规模(如FP/LOC)是成本估算基础 → 先估规模再算成本(选择题4B√) | 成本估算方法排除关键路径法(选择题5D√) |
💡 冲刺锦囊:
- Fibonacci估算:遇“略多/略少”必须跳级(如3→5或3→2),禁止选中间值!
成本 vs 预算:
- 估算→总成本预测
- 预算→成本按时间段分配(选择题9B√)
直接 vs 间接成本:
- 直接=项目专属(开发工资)
- 间接=组织分摊(房租)→ 判断题9×
- 功能点计数项:口诀“外内外查” → 外部输入/输出/接口文件 + 内部文件 + 查询
第七章
二、判断题解析
一个工作也可以通过多个活动完成。(√)
答案:√
原因:工作 vs 活动:
- 工作(Work):宏观目标(如“开发登录模块”)
- 活动(Activity):具体步骤(如“设计界面”“编写代码”“测试功能”)
- 关系:一个工作可拆解为多个活动,符合 WBS(工作分解结构) 思想。
在项目进行过程中,关键路径是不变的。(×)
答案:×
原因:- 关键路径:项目中最长耗时路径,决定项目最短工期。
- 变化原因:任务延迟、资源调整、需求变更等都可能改变关键路径。
- 考点:关键路径是动态的,需持续跟踪。
在PDM网络图中,箭线表示逻辑关系,节点表示活动。(√)
答案:√
原因:PDM(前导图) :
- 节点 = 活动(如“开发”“测试”)
- 箭线 = 逻辑关系(如“测试必须在开发完成后开始”)
- 对比ADM(箭线图) :箭线表示活动,节点表示事件。
项目各项活动之间不存在相互联系与依赖关系。(×)
答案:×
原因:- 依赖关系必然存在:例如“测试”依赖“编码”,“部署”依赖“测试”。
- 类型:强制依赖(技术约束)、自由依赖(团队决策)、外部依赖(客户提供材料)。
过度分配属于资源冲突。(√)
答案:√
原因:- 资源冲突:资源需求 > 可用量(如1人被同时分派3个任务)。
- 过度分配:典型资源冲突,需通过资源平衡解决(如调整任务时间)。
浮动是在不增加项目成本的条件下可延迟的时间量。(×)
答案:×
原因:- 浮动(时差) :任务可延迟但不影响总工期的最大时间。
- 成本无关:浮动仅关联进度,延迟可能间接增加成本(如人员闲置),但定义不涉及成本。
使用应急法压缩时间时,不一定要在关键路径上选择活动。(×)
答案:×
原因:- 应急法(赶工) :通过增加资源压缩关键路径上的任务(如加班、加人)。
- 关键路径原则:只有压缩关键路径才能缩短总工期,非关键路径压缩无效。
时间是项目规划中灵活性最小的因素。(√)
答案:√
原因:- 时间刚性:截止日期常由客户/市场决定,难以调整。
- 对比:成本可追加预算,范围可协商,时间弹性最小。
外部依赖关系又称强制性依赖关系。(×)
答案:×
原因:- 强制依赖:技术/法规限制(如“必须先建地基再盖楼”)。
- 外部依赖:项目与非项目活动的关联(如“等待客户提供数据”)。
- 区别:强制依赖不一定是外部的(如内部技术约束)。
当活动时间不确定性大时,应采用CPM估计。(×)
答案:×
原因:- CPM(关键路径法) :适用于确定性工期(如每步时间明确)。
- 不确定性场景:应用PERT(计划评审技术) ,用三点估算(乐观/悲观/最可能)。
敏捷项目采用远粗近细计划,发布计划=远期,迭代计划=近期。(√)
答案:√
原因:敏捷计划层级:
- 发布计划:粗粒度(未来3-6个月要交付的功能范围)。
- 迭代计划:细粒度(当前2-4周内具体任务)。
- 灵活性:随项目进展逐步细化,适应需求变化。
三、选择题解析
下面说法中不正确的是( )
✓ D. EF=ES+lag
- 错误原因:
EF
(最早结束时间)=ES
(最早开始时间)+duration
(任务工期)。Lag 是任务间的等待时间(如开发结束需等待2天才能测试),不参与单个任务时间计算。
- 错误原因:
✓ 其他选项正确:
- A.
EF=ES+duration
→ 基本公式 - B.
LS=LF-duration
→ 最晚开始=最晚结束-工期 - C.
TF=LS-ES=LF-EF
→ 总浮动计算公式
- A.
“软件编码完成之后,我才可以对它进行软件测试”说明的依赖关系是( )
✓ A. 强制性依赖关系
- 由技术逻辑决定(无编码则无法测试),不可跳过。
✗ 错误选项:
- B. 软逻辑关系:团队可调整顺序(如先测模块A或B)
- C. 外部依赖关系:依赖项目外因素(如等客户审批)
- D. 里程碑:标记关键节点,非依赖类型
可以显示任务工期、开始/结束时间、资源信息的图是( )
✓ A. 甘特图
- 条形图直观展示时间轴上的任务进度和资源分配。
✗ 错误选项:
- B. 网络图:展示任务逻辑关系(如箭头方向),不直接显示资源
- C. 里程碑图:仅标记关键节点(如“产品发布”)
- D. 资源图:显示资源负荷情况,不强调时间细节
项目后期冲突的主要原因是( )
✓ C. 进度问题
- 临近截止日期,进度延迟风险成为焦点(如加班争议)。
✗ 错误选项:
- A. 优先级问题:常见于项目初期(需求不明确)
- B. 人力问题:常见于中期(资源调配冲突)
- D. 费用问题:可能全程存在,但后期影响弱于进度
项目计划中灵活性最小的因素是( )
✓ A. 时间
- 截止日期通常不可协商(如合同约定)。
✗ 错误选项:
- B. 人工成本:可通过加人/外包缓解
- C. 管理:流程可优化(如敏捷迭代)
- D. 开发:技术方案可调整
以下哪一项不是任务之间的关系?( )
✓ D. 结束-开始-结束
- 不存在此逻辑关系。
✓ 其他选项为标准关系:
- A. 结束-开始(FS):前任务结束,后任务才能开始
- B. 开始-开始(SS):前任务开始,后任务才能开始
- C. 结束-结束(FF):前任务结束,后任务才能结束
快速跟进是指( )
✓ A. 采用并行执行任务,加速项目进展
- 例:设计完成50%时就开始编码(原需100%完成)。
✗ 错误选项:
- B. 用一个任务取代另外的任务 → 属于范围变更
- C. 减少任务数量 → 属于范围缩减
- D. 减轻项目风险 → 是风险管理目标
下面哪一项将延长项目的进度?( )
✓ A. Lag
- Lag = 任务间的强制等待时间(如混凝土养护3天),直接延长总工期。
✗ 错误选项:
- B. Lead:任务重叠执行(如开发完成80%时开始测试),缩短工期
- C. 赶工:通过增加资源压缩关键路径任务(如加班),缩短工期
- D. 快速跟进:并行任务,缩短工期
可以决定进度的灵活性的因素是( )
✓ B. 总浮动
- 总浮动 = 任务可延迟但不影响总工期的最大时间(灵活性来源)。
✗ 错误选项:
- A. PERT:一种估算工期的技术(三点估算法),不决定灵活性
- C. ADM(箭线图):网络图类型,仅展示逻辑关系
- D. 赶工:进度压缩技术,牺牲成本换时间
可以表示敏捷项目进度及剩余任务的图是( )
✓ B. 燃尽图
- 横轴:时间(迭代天数)
- 纵轴:剩余工作量(故事点/任务数)
- 作用:实时显示剩余任务量趋势(理想线 vs 实际线)。
✗ 错误选项:
- A. 燃起图:显示已完成工作量,不强调剩余任务
- C. 里程碑图:仅标记关键节点,无法跟踪迭代进度
- D. 网络图:展示任务依赖,非敏捷专用进度工具
突击重点总结
核心概念 | 速记口诀 | 易错点 |
---|---|---|
关键路径 | 最长路径定工期,动态变化需监控 | 关键路径可能改变(判断题2×) |
浮动时差 | 总浮动=LS-ES,不增成本可延迟 | 浮动定义与成本无关(判断题6×) |
依赖关系 | 强制(技术)、自由(团队)、外部(客户) | “编码后测试”是强制依赖(选择题2A) |
进度压缩 | 赶工(加资源)、快速跟进(并行) | 赶工必须针对关键路径(判断题7×) |
敏捷计划 | 发布计划粗,迭代计划细 | 燃尽图看剩余任务(选择题10B) |
💡 最后叮嘱:
- 遇到 “Lag/Lead” 题:Lag=拖延时间(进度+),Lead=提前重叠(进度-)
- 遇到 “浮动”题:总浮动(TF)决定进度灵活性,非关键路径才有浮动
- 甘特图是进度管理的“瑞士军刀”,燃尽图是敏捷的“进度仪表盘”
第八章
二、判断题解析
- 质量是满足要求的程度,包括符合规定要求和客户隐含需求。(√)
答案:√
原因:质量的核心是符合性(满足书面规范)和适用性(满足用户未明说的期望),符合ISO 9000标准定义。 - 软件质量是软件满足明确说明或隐含需求的程度。(√)
答案:√
原因:软件质量定义与通用质量概念一致,强调功能性需求(如功能正确)和非功能性需求(如易用性、性能)。 软件质量可以通过后期测试得以提高。(×)
答案:×
原因:- 测试仅能发现缺陷,无法提升代码本身质量。
- 质量提升依赖前期实践(如设计评审、代码规范、持续集成)。
关键点:质量是“构建”出来的,不是“测试”出来的。
- 质量计划可以确定质量保证人员的特殊汇报渠道。(√)
答案:√
原因:质量计划包含角色职责定义(如QA直接向高层汇报),确保质量监督独立性。 软件质量是代码正确的程度。(×)
答案:×
原因:软件质量包含多维度:- 代码正确性(基础)
- 可维护性、可扩展性、安全性等(高阶属性)
反例:代码正确但难以维护,仍属低质量。
- 敏捷项目要求全程的质量审查。(✅)
答案:×
原因:敏捷通过自动化测试、持续集成、迭代评审等轻量级实践保障质量,而非传统“全程审查”。
三、选择题解析
下列不属于质量管理过程的是( )
✓ D. 质量优化
- 原因:标准过程为质量计划→质量保证→质量控制(PMBOK定义),“优化”是目标而非独立过程。
✗ 错误选项:
- A. 质量计划:定义质量标准及实现方法
- B. 质量保证:审计过程是否合规(如代码评审)
- C. 质量控制:检查结果是否达标(如测试)
项目质量管理的目标是满足( )的需要
✓ C. 项目
- 原因:质量管理的核心是满足项目干系人要求(范围、时间、成本平衡),而非单一方。
✗ 错误选项:
- A. 老板 / B. 项目经理 / D. 组织:均为干系人子集,不全面。
下列属于质量成本的是( )
✓ A. 预防成本
原因:质量成本(COQ)包含:
- 预防成本(培训、流程设计)
- 评估成本(测试、检查)
- 失败成本(返工、赔偿)
✗ 错误选项:
- B. 缺陷数量:是结果指标,非成本类型
- C. 预测成本:无此术语
- D. 缺失成本:通常归入失败成本
下列不是质量计划方法的是( )
✓ C. 抽样分析
- 原因:抽样分析是质量控制技术(如测试抽样),非计划阶段方法。
✓ 其他选项是质量计划方法:
- A. 质量成本分析:权衡质量投入与收益
- B. 因果分析图(鱼骨图):追溯问题根源
- D. 基准对照:借鉴行业最佳实践
下列不是软件质量模型的是( )
✓ D. Mark质量模型
- 原因:不存在公认的“Mark质量模型”。
✓ 其他选项是经典模型:
- A. Boehm模型:分层定义软件特性(如可移植性)
- B. McCall模型:聚焦产品运行、修改、转移三维度
- C. ISO/IEC 9216:国际标准模型(后演进为ISO 25010)
( )可以降低质量控制的成本
✓ B. 使用抽样统计
- 原因:抽样用少量样本推断整体质量,减少全量测试成本(如抽检20%模块)。
✗ 错误选项:
- A. 进行过程分析:属质量保证,预防成本可能增加
- C. 全程监督:成本极高,不现实
- D. 质量审计:属质量保证,增加过程审查成本
McCall质量模型不包含( )
✓ C. 产品特点
原因:McCall模型三大维度为:
- 产品运行(正确性、效率)
- 产品修改(可维护性、灵活性)
- 产品转移(可移植性、复用性)
- “产品特点”是模糊术语,非模型维度。
- ✗ 错误选项:A/B/D均为模型维度。
下面( )不是敏捷项目的质量实践
✓ D. 需求规格编写过程审计
- 原因:敏捷强调轻文档,需求通过用户故事、验收测试表达,拒绝传统审计。
✓ 其他选项是敏捷实践:
- A. 结对编程:双人实时互审代码
- B. TDD(测试驱动开发):先写测试再编码
- C. 迭代评审:每轮演示验收成果
核心概念速记表
类别 | 正确概念 | 常见错误 | 避坑技巧 |
---|---|---|---|
质量定义 | 符合性 + 适用性 | 仅限“代码正确”(判断题5×) | 想用户:显性+隐性需求 |
质量成本 | 预防/评估/失败成本 | 混淆“缺陷数量”(选择题3B) | 成本=花钱做的事 |
McCall模型 | 运行、修改、转移 | 虚构“产品特点”(选择题7C) | 三维度对应软件生命周期 |
💡 关键总结:
- 预防 > 检查:质量靠前期设计(判断题3×)
- 抽样是成本利器:用小样本控制大风险(选择题6B)
- 敏捷拒绝形式化:要代码评审不要文档审计(选择题8D)
第九章
二、判断题解析
- 一个软件配置项可能有多个标识。(×)
答案:×
原因:每个配置项必须有唯一标识符(如文件路径+版本号),避免混淆。多标识会导致版本追踪混乱。 - 基线提供了软件开发阶段的一个特定点。(×)
答案:×
原因:基线是经过正式评审并冻结的配置项集合(如需求基线、设计基线),代表阶段成果,而非“时间点”。 - 有效的项目管理能够控制变化,以最有效的手段应对变化,不断命中移动的目标。(√)
答案:√
原因:变更控制是项目管理核心能力,通过流程(如变更请求、影响分析)平衡需求变化与项目目标。 - 一个(些)配置项形成并通过审核,即形成基线。(√)
答案:√
关键点:基线成立条件 = 配置项完成 + 正式评审通过 + 冻结。 - 软件配置项是项目需定义其受控于软件配置管理的款项,每个项目的配置项是相同的。(×)
答案:×
原因:配置项因项目而异(如代码、文档、测试用例),不存在统一标准。 - 基线的修改不需要每次都按照正式的程序执行。(×)
答案:×
原则:基线修改必须走变更控制流程(申请→评估→批准→实施),否则破坏稳定性。 - 基线产品是不能修改的。(×)
答案:×
纠正:基线可修改,但需严格受控(经SCCB批准后按流程更新版本)。 - 基线修改应受到控制,但不一定要经SCCB授权。(×)
答案:×
关键角色:SCCB(软件配置控制委员会)是基线变更的唯一决策机构。 - 变更控制系统包括从项目变更申请、变更评估、变更审批到变更实施的文档化流程。(√)
答案:√
流程完整性:四大环节缺一不可,且需全程文档化追踪。 - 持续交付领域强调对项目所有的相关产物及其之间的关系都要进行有效配置管理(√)
答案:√
原因:持续交付要求全产物版本受控(代码、环境、脚本等),确保发布一致性。 - 持续交付更倾向于使用基于分支的开发模式(×)
答案:×
最佳实践:持续交付提倡主干开发(Trunk-Based Development) ,减少分支合并冲突,加速集成。
三、选择题解析
下列不属于SCCB的职责的是( )
✓ D. 提出变更申请
- 原因:SCCB负责评审与决策变更(如评估影响、审批请求),而变更申请由项目成员(如开发/测试人员)提出。
✗ 错误选项:
- A. 评估变更 → SCCB核心职责
- B. 与项目管理层沟通 → 反馈变更影响
- C. 对变更进行反馈 → 决策结果通知
关于基线的描述,正确的是( )
✓ B. 可以变化,但是必须通过基线变更控制流程处理
- 原则:基线需平衡稳定性和灵活性,变更必须受控。
✗ 错误选项:
- A. 不可变化 → 违反实际需求(如修复基线缺陷)
- C. 所有项目必须定义基线 → 小型项目可能简化配置管理
- D. 基线变更必须修改需求 → 需求基线变更才需改需求,其他基线(如设计)不影响
软件配置管理无法确保以下哪种软件产品属性( )
✓ A. 正确性
- 关键区分:配置管理保证版本一致性、完整性、可追溯性,但正确性需通过测试/评审实现。
✗ 错误选项:
- B. 完整性 → 配置管理确保无遗漏产物
- C. 一致性 → 保障配置项间依赖关系正确
- D. 可控性 → 变更流程的核心目标
变更控制需要关注的是( )
✓ B. 标识变更,提出变更,管理变更
- 流程本质:对变更进行全生命周期管理(识别→提案→控制)。
✗ 错误选项:
- A. 阻止变更 → 变更不可避免,需管理而非阻止
- C. 管理SCCB → SCCB是决策组织,非管理对象
- D. 客户的想法 → 是变更来源,非管理动作
以下哪项不是项目配置管理中可能遇到的问题?( )
✓ B. 甲方与乙方在资金调配上存在意见差异
- 原因:资金调配属合同与财务管理范畴,与配置管理无关。
✓ 其他选项是典型配置管理问题:
- A. 找不到历史版本 → 版本控制缺失
- C. 未经授权修改 → 变更流程失效
- D. 版本混乱导致失败 → 协同开发配置失控
高频易错点对比表
概念 | 正确定义 | 常见误解 | 避坑技巧 |
---|---|---|---|
配置项标识 | 唯一标识符(如src/main.java@v1.0 ) | 允许多个标识(判断题1×) | “配置项≈身份证号” |
基线修改 | 需SCCB审批 + 正式流程 | 可直接修改(判断题6×/8×) | 想成“法律修订”:需议会批准 |
SCCB职责 | 变更评估与决策(选择题1D) | 包含提出变更申请 | SCCB是“法官”,非“原告” |
配置管理目标 | 保障一致性/完整性/可控性(选择题3A) | 确保代码正确性 | 正确性归测试,配置管理管版本 |
持续交付开发模式 | 主干开发为主(判断题11×) | 依赖分支开发 | 分支开发→合并地狱;主干→高效 |
💡 考场速记口诀:
- 基线三原则:评审通过才成立、修改必须走流程、SCCB说了算
- 配置管理四不管:不管正确性、不管钱、不管客户想法、不管SCCB行政
- 持续交付要记牢:全产物受控 + 主干开发
第十章
二、判断题解析
- 项目干系人是项目计划的一部分。(√)
原因:干系人管理是项目计划的核心内容,包括识别干系人、分析其需求,并制定沟通策略,确保其参与项目决策。 - 项目型的优点是可以资源共享。(×)
原因:项目型组织中资源专用于项目,资源共享程度低;矩阵型或职能型组织才强调资源共享(如跨项目共用设备或人员)。 - 应尽量多建立一些沟通渠道。(×)
原因:过多的沟通渠道会导致信息过载和混乱。项目管理强调建立 适量、高效 的渠道(如定期会议、报告),而非追求数量。 项目沟通的基本原则是及时性、准确性、完整性和可理解性(√)
原因:这是沟通管理的核心原则:- 及时性(信息快速传递)
- 准确性(内容无误)
- 完整性(信息全面)
- 可理解性(接收方清晰理解)。
- 在IT项目中,成功的最大威胁是沟通的失败(√)
原因:IT项目复杂度高、依赖协作,沟通失败(如需求误解、信息延迟)是项目延期或失败的首要原因(PMI研究支持)。 - 责任分配矩阵是明确项目团队成员的角色与职责的有效工具(√)
原因:责任分配矩阵(如RACI矩阵)明确划分成员的任务(Responsible、Accountable等),减少职责模糊。 - 口头沟通不是项目沟通的方式(×)
原因:口头沟通(如会议、电话)是项目常用方式,适合快速讨论和反馈;项目沟通方式包括口头、书面、非正式等。 对于紧急的信息,应该通过口头的方式沟通;对于重要的信息,应采用书面的方式沟通(√)
原因:- 紧急信息:口头沟通(如电话)速度快,便于即时响应。
- 重要信息:书面沟通(如邮件、文档)可追溯、避免歧义。
- 沟通计划包括确定谁需要信息,需要什么信息,何时需要信息,以及如何接收信息等(√)
原因:沟通计划的核心是定义 信息需求(干系人、内容、频率、传递方式),确保信息高效流动。 - 敏捷团队的人员一般在3~9人,而且一般集中地在一个场地开发,可以围坐一个桌子开会(√)
原因:敏捷方法(如Scrum)要求小团队(3-9人)和 集中办公(co-location),以促进面对面协作和快速决策。
三、选择题解析
(A)以图形方式展示项目团队成员及其报告关系这样可以减少沟通渠道,减少成本
答案:A. 项目组织图
原因:项目组织图直观显示成员间的报告关系,简化沟通层级,减少冗余渠道(如避免跨部门混乱)。
错误选项:- B. 甘特图:展示进度,非组织结构。
- C. 网络图:显示任务依赖,非人员关系。
- D. RAM图:责任分配矩阵,定义角色但非报告关系。
- 下面不是敏捷角色的是(D)
答案:D. 合同管理者
原因:敏捷核心角色包括产品负责人(定义需求)、团队促进者(Scrum Master)、跨职能成员(开发团队),合同管理者属传统项目管理范畴。
错误选项:A/B/C均为标准敏捷角色。 在项目管理的3种组织结构中,适用于主要由一个部门完成的项目或技术比较成熟的项目组织结构是(C)
答案:C. 职能型组织结构
原因:职能型组织由单一部门主导项目,适合技术成熟、无需跨部门协作的场景(如标准化产品开发)。
错误选项:- A. 矩阵型:适合跨部门复杂项目。
- B. 项目型:适合独立性强的大型项目。
- 项目经理花在沟通上的时间是(B)
答案:B. 75%-90%
原因:项目经理主要职责是协调干系人、解决冲突和传递信息,研究表明其75%-90%时间用于沟通(PMBOK指南)。
错误选项:其他比例不符合项目管理实践。 在(C)组织结构中,项目成员没有安全感
答案:C. 项目型
原因:项目型组织中,成员随项目结束可能面临失业或重新分配,缺乏长期职位保障。
错误选项:- A. 职能型:成员有部门归属,稳定性高。
- B/D. 矩阵型:成员兼顾项目和部门,安全感较强。
- 下列关于干系人的描述中,不正确的是(D)
答案:D. 所有项目人员
原因:干系人包括影响项目或被项目影响的 内外部各方(如客户、供应商),但非所有项目人员(如部分支持人员可能无关)。
错误选项:A/B/C正确描述干系人影响范围。 - 编制沟通计划的基础是(A)
答案:A. 沟通需求分析
原因:沟通计划基于 需求分析,识别干系人信息需求(如谁需要什么、何时需要),再制定策略。
错误选项:B/C/D是输入但非基础。 项目团队原来有5个成员,现在人员扩充,又增加了3个成员这样沟通渠道增加了(A)
答案:A. 2.8倍
原因:沟通渠道数公式为 ( \frac{n(n-1)}{2} )。- 原渠道:( \frac{5 \times 4}{2} = 10 )
- 新渠道:( \frac{8 \times 7}{2} = 28 )
- 增加倍数:( \frac{28}{10} = 2.8 )倍。
- 对于项目中比较重要的通知,最好采用(B)沟通方式
答案:B. 书面
原因:重要通知需 可追溯、防篡改,书面形式(如邮件、文档)确保信息准确性和正式性。
错误选项:A/C/D(口头、网络、电话)适合非正式或紧急场景,但易遗漏或误解。 在一个高科技公司,项目经理正在为一个新的项目选择合适的组织结构,这个项目涉及多的领域和特性,他应该选择(A)组织结构
答案:A. 矩阵型
原因:矩阵型组织整合多部门资源,适合 跨领域复杂项目(如高科技项目需设计、开发、测试协作),平衡职能专业性和项目目标。
错误选项:- B. 项目型:适合独立项目,但资源利用率低。
- C. 职能型:难以协调跨部门工作。
核心概念速记表
类别 | 关键点 | 易错提示 |
---|---|---|
沟通原则 | 及时、准确、完整、可理解(判断题4) | 避免“多建渠道”(判断题3×) |
敏捷团队 | 3-9人集中办公(判断题10√) | 合同管理者非敏捷角色(选择题2D) |
组织结构 | 职能型→单一部门;矩阵型→跨领域(选择题3C/10A) | 项目型→成员无安全感(选择题5C) |
沟通渠道计算 | 公式 ( \frac{n(n-1)}{2} )(选择题8A) | 增加3人后渠道增2.8倍(非线性) |
干系人范围 | 包含内外部影响者(选择题6D) | 非“所有项目人员” |
💡 总结:
- 沟通是核心:项目经理75%-90%时间投入沟通(选择题4B),失败是IT项目最大威胁(判断题5√)。
- 结构决定效率:矩阵型平衡资源与协作(选择题10A),项目型牺牲安全感(选择题5C)。
- 敏捷小团队:3-9人集中办公,避免传统角色(如合同管理者)(判断题10√,选择题2D)。
<br/>
二、判断题解析
- 任何项目都是有风险的。(√)
原因:项目受资源、时间、技术等约束,存在不确定性(如需求变更、资源短缺),风险必然存在。 - 风险是损失发生的不确定性,是对潜在的、未来可能发生损害的一种度量。(✅)
风险识别、风险评估、风险规划、风险控制是风险管理的4个过程。(√)
流程:标准风险管理过程:- 识别(发现风险)→ 2. 评估(分析概率/影响)→ 3. 规划(制定对策)→ 4. 控制(监控应对)。
应对风险的常见策略是回避风险、转移风险、损失控制和自留风险。(√)
四大策略:- 回避(取消高风险任务)
- 转移(如购买保险)
- 减轻(即损失控制,降低概率/影响)
- 接受(自留风险,主动或被动承担)。
- 项目的风险几乎一样。(×)
原因:风险因项目 类型、规模、环境 而异(如软件项目需求风险高,建筑项目安全风险高)。 - 购买保险是一种回避风险的应对策略(×)
原因:保险属于 风险转移(将损失后果转嫁给保险公司),非回避(回避是彻底消除风险源)。 - 敏捷项目没有长期计划,这本身也是一个风险,因为存在一些无法识别的风险。(✅)
三、选择题解析
- 下列不属于项目风险的三要素的是( )
✓ B. 事件的产生原因
原因:风险三要素 = 风险事件(什么可能发生) + 发生概率(可能性) + 影响(后果)。
错误选项:A/C/D 均为三要素组成部分。 下列属于可预测风险的是( )
✓ C. 人员调整
关键区分:- 可预测风险:有先兆可管理(如员工离职率、季节性故障)。
- 不可预测风险:突发且难预判(如选项A/B/D)。
- 下列不是风险管理过程的是( )
✓ D. 风险收集
标准过程:识别→评估→规划→控制。“风险收集”非标准术语,属于“识别”的子活动。
错误选项:A/B/C 是风险管理核心过程。 - 下列说法错误的是( )
✓ D. 项目风险是由风险发生的可能性决定的
纠正:风险 = 概率 × 影响,单一因素不能决定风险(如高概率低影响事件可能风险较小)。
其他选项正确:A(三要素)√;B(四过程)√;C(四大策略)√。 项目经理进行技术培训应对新技术风险,属于什么策略?( )
✓ B. 损失控制
原因:技术培训旨在 降低风险发生概率或影响(如减少技术失误),属于 减轻策略(即损失控制)。
错误选项:- A. 回避(放弃新技术)
- C. 转移(外包技术模块)
- D. 自留(无措施直接承担)。
下列不属于风险评估方法的是( )
✓ D. 二叉树分析
原因:二叉树分析用于 金融期权定价,非风险评估。
常用风险评估方法:- A. 盈亏平衡分析(量化风险对利润影响)
- B. 模拟法(如蒙特卡洛模拟)
- C. 决策树分析(计算预期货币值EMV)。
风险管理核心知识速记表
概念 | 关键点 | 易错题示例 |
---|---|---|
风险定义 | 包含威胁与机会,非仅损失(判断题2×) | 修正为“目标偏离不确定性” |
风险三要素 | 事件 + 概率 + 影响(选择题1B) | “原因”不属于三要素 |
应对策略 | 回避/转移/减轻(损失控制) /接受(判断题4√,选择题5B) | 保险=转移≠回避(判断题6×) |
可预测风险 | 有预警信号(如人员流动),可提前规划(选择题2C) | 区别于突发风险(如恶劣环境) |
风险评估工具 | 决策树、模拟法、盈亏平衡分析(选择题6D) | 二叉树分析属金融领域 |
💡 避坑指南:
- 风险 ≠ 损失:风险是双刃剑(威胁+机会),判断题2的定义片面。
- 减轻 vs 回避:培训/备份是减轻(降低概率),取消任务是回避(彻底消除)。
- 概率 × 影响:选择题4的D选项错在忽略风险二元性。
十二章
二、判断题解析
- 软件项目外包的实质是软件开发过程从公司内部部分或者全部延伸到公司外部的过程(×)
原因:外包是 将工作转移给外部供应商,而非简单“延伸”。核心是 责任和所有权的转移(如供应商自主开发),公司内部不再直接控制过程。 对于甲方来说,风险最高的是CPCC合同类型,风险最低的是FFP合同类型,乙方则相反(√)
原因:- 甲方风险:CPCC(成本加成本百分比)中,供应商成本越高则利润越高(成本×百分比),甲方成本失控风险最高;FFP(固定总价)中甲方支付固定金额,风险最低。
- 乙方风险:FFP需承担超支风险(如实际成本>合同价),CPCC成本实报实销,乙方风险最低。
- 如果一个项目的合同类型是固定价格(FFP),合同价格是100万元,实际花费160万元,则项目结算金额为160万元(×)
原因:FFP合同下,结算金额=合同价格(100万元) 。乙方承担超支风险(60万元损失),甲方不额外支付。 - 成本加激励费用(CPIF)合同具有激励机制(√)
原因:CPIF合同中,乙方获得 实际成本报销+激励奖金。奖金与成本绩效挂钩(如节约成本则奖励),驱动乙方控制成本。 - 《敏捷宣言》认为“客户协作高于合同协商”(√)
原因:敏捷价值观第四条明确 “客户协作高于合同谈判” ,强调灵活响应需求变化,而非僵化遵守合同条款。
三、选择题解析
- 下列合同类型中,卖方承担的风险最大的是(D)
答案:D. 固定价格
原因:固定价格合同(FFP)中,卖方承担全部成本超支风险(如实际成本>合同价则亏损)。
其他选项:A/B/C均为成本补偿类合同,买方承担成本风险。 某项目采用成本加奖金合同,预算成本20万元,利润4万元,奖励分配80/20,实际成本16万元,则项目总价为(C)
答案:C. 20.8万元
计算:- 成本节约 = 20万 - 16万 = 4万元
- 卖方奖金 = 节约成本 × 20% = 4万 × 0.2 = 0.8万元
- 卖方利润 = 基础利润 + 奖金 = 4万 + 0.8万 = 4.8万元
- 总价 = 实际成本 + 利润 = 16万 + 4.8万 = 20.8万元
- 合同是需要靠(D)约束的
答案:D. 相关法律法规
原因:合同具有 法律强制力,依赖《合同法》等法规保障执行(如违约可诉讼)。共识/道德/责任是基础,但无法律则无强制约束。 下面哪项不是敏捷项目设计的动态特性合同签署技术(D)
答案:D. 固定价格
原因:敏捷项目需适应需求变化,动态合同技术包括:- A. 多层结构(分阶段签订合同)
- B. 总结增量(按迭代交付付款)
- C. 动态范围方案(范围可调整)
固定价格(D) 刚性锁定范围/价格,不符合敏捷灵活性。
合同类型核心知识总结
合同类型 | 关键特征 | 风险承担方 |
---|---|---|
固定价格(FFP) | 总价固定,超支由卖方承担 | 卖方风险最大(选择题1D) |
成本加百分比(CPCC) | 买方报销成本+成本比例利润 | 买方风险最大(判断题2√) |
成本加激励(CPIF) | 成本报销+绩效奖金(如节约奖励) | 风险共担,有激励机制(判断题4√) |
动态合同技术 | 多层结构/总结增量/动态范围方案 | 支持敏捷协作(选择题4D×) |
💡 关键结论:
- 外包本质:是责任转移,非过程延伸(判断题1×)。
- FFP结算铁律:结算额=合同价,无关实际成本(判断题3×)。
- 敏捷合同优先级:协作高于合同条款(判断题5√),固定价格违背敏捷原则(选择题4D)。
- 法律约束力:合同效力最终由法律保障(选择题3D)。
十三章
判断题解析
- 范田和成本成一定的正比关系(✓)
解析:"范田"应为"范围"(打字错误)。范围与成本成正比关系:范围扩大通常导致成本增加(例如,需求增加需更多资源),反之范围缩小可降低成本。题干描述正确。 进度和成本是关系最为密切的两个要素,几乎成对立关系,进度的缩短一定依靠成本增加实现,而成本的降低也一定以牺牲工期进度为代价(✗)
解析:进度与成本并非绝对对立:- 进度缩短不一定依赖成本增加(例如,通过优化流程或技术提升可加速进度而不增加成本)。
- 成本降低不一定牺牲进度(例如,通过减少范围或提高效率可实现)。
题干中"一定"过于绝对,实际项目管理中需权衡多因素(如范围、质量),故错误。
项目管理过程是一个集成的过程,范围计划、进度、成本、质量、风险是相互联系的(✓)
解析:项目管理是系统性集成过程,各要素相互影响:- 范围变更影响进度和成本。
- 质量要求变化可能增加成本或延长进度。
- 风险事件可能导致范围、进度、成本调整。
题干描述正确。
- 软件项目管理的最重要的四个要素是范围、质量、进度和风险(✗)
解析:软件项目管理核心四要素是范围、进度、成本、质量(即"三重约束"扩展为"四重约束")。风险是重要因素,但非核心四要素之一。题干忽略了"成本",故错误。
选择题解析
项目集成管理包括以下内容,除了(C)
答案:C. 软件设计文档
解析:项目集成管理聚焦整体协调与平衡,包括:- A. 计划集成与跟踪控制(如制定综合计划)。
- B. 要素协调(如范围、进度联动)。
- D. 目标权衡(如成本与进度取舍)。
C. 软件设计文档是技术交付物,属于范围管理,非集成管理范畴。
设成本C是范围S、质量Q、进度T的函数C=F(S,Q,T),在成本或时间不充足的情况下,可以通过减小范围或者(C)来解决。
答案:C. 降低质量
解析:成本或时间不足时,解决方案包括:- 减小范围(减少功能需求)。
- 降低质量(如简化测试、降低性能标准),从而减少资源消耗。
A. 提高质量会增加成本/时间;B. 增加成员可能抬高成本;D. 选项错误。
项目管理过程中的进度目标、成本目标、质量目标、范围目标等各个目标之间是(B)
答案:B. 相互关联和制约的
解析:项目目标具有内在关联性:- 范围扩大 → 进度延长或成本增加。
- 进度缩短 → 成本增加或质量降低。
- 质量提高 → 成本增加或范围调整。
A/D忽略关联性;C片面强调单一目标重要性。
核心知识总结
概念 | 关键点 |
---|---|
范围-成本关系 | 正比关系:范围↑ → 成本↑(判断题1✓)。 |
进度-成本权衡 | 非绝对对立:可通过优化而非单纯增加资源缩短进度(判断题2✗)。 |
目标关联性 | 范围、进度、成本、质量相互制约(选择题3B)。 |
四要素优先级 | 软件项目管理核心:范围、进度、成本、质量(判断题4✗)。 |
动态解决方案 | 成本/时间不足时:减范围或降质量(选择题2C)。 |
集成管理本质 | 协调全局目标,不包括技术文档(选择题1C)。 |
十四章
判断题解析
- 记录反映当前项目状态的项目性能数据是控制项目的基础(✓)
解析:项目性能数据(如进度、成本实际值)是监控过程组的输入,用于比较计划与实际,是采取纠正措施的基础。 - 项目进度成本控制的基本目标是在给定的限制条件下,用最短时间、最小成本、以最小风险完成项目工作(✓)
解析:进度成本控制的核心是优化约束条件(范围、时间、成本、质量、风险),追求高效交付。 - 代码走查是在代码编写阶段,开发人员自己检查自己的代码(✓)
解析:代码走查(Walkthrough)是开发人员自查或交叉检查代码的静态测试方法,目的是早期发现缺陷。 - 在使用应急法压缩进度时,不一定要在关键路径上选择活动来进行压缩(✗)
解析:进度压缩技术(如赶工、快速跟进)必须优先针对关键路径活动(非关键路径压缩不影响总工期)。 累计费用曲线中某时间点ACWP比BCWS高,意味着实际成本比计划高,二者差值即成本差异(✓)
解析:ACWP
(实际成本) >BCWS
(计划价值) → 成本超支。- 成本差异
CV = BCWP(挣值) - ACWP
,但题干描述成本偏高现象正确。
CPI=0.90说明目前的预期成本超出计划的90%(✗)
解析:CPI = EV / AC
(成本绩效指数),CPI=0.90 表示投入1元仅产出0.9元价值,即成本超支10%(非超出90%)。
- 技术评审的目的是尽早发现工作成果中的缺陷,帮助开发人员及时消除缺陷,有效提高产品质量(✓)
解析:技术评审(如代码审查、设计评审)是预防性质量保证活动,核心是早期缺陷发现。 - 软件测试的目的是证明软件没有错误(✗)
解析:测试目的是发现缺陷而非证明无缺陷(无法穷尽测试),通过缺陷修复提升质量。
选择题解析
成员提出超出WBS基线的要求,项目经理坚持仅完成原范围基线 → 这是(B)的例子
答案:B. 范围管理
解析:- 范围管理包括定义、控制及防止范围蔓延(题干中项目经理控制变更)。
- C. "范围蔓延"是未受控的范围扩大,但题干体现的是主动管理行为。
到2014.5.23计划完成1000元(PV),实际完成850元(EV),花费900元(AC) → 成本偏差(CV)和进度偏差(SV)分别是?
答案:A. CV=-50元, SV=-150元
解析:CV = EV - AC = 850 - 900 = -50
(成本超支50元)。SV = EV - PV = 850 - 1000 = -150
(进度落后150元)。
CPI=90% 说明(B)
答案:B. 投入1元产生0.9元的效果
解析:CPI = EV / AC = 0.9
→ 每投入1元实际获得价值0.9元,即成本效率低下。- 选项A/C错误(CPI不直接表示超支百分比)。
- 进度控制重要的组成部分是(A)
答案:A. 确定进度偏差是否需要采取纠正措施
解析:进度控制的核心是分析偏差(如SV)并决定是否行动(如调整资源、压缩进度)。 - 当项目进展到(B)左右时,CPI处于稳定
答案:B. 20%
解析:项目管理经验表明,项目完成20% 后,CPI趋于稳定(早期波动较大)。 - 抽样统计的方法中,(B)
答案:B. 以小批量的抽样为基准进行检验
解析:抽样检验通过小批量样本推断整体质量,是成本效益较高的方法(选项A/D错误,C过于绝对)。
核心概念速查表
术语 | 公式/定义 | 应用场景 |
---|---|---|
CV(成本偏差) | CV = EV - AC | >0:节约;<0:超支 |
SV(进度偏差) | SV = EV - PV | >0:超前;<0:落后 |
CPI | CPI = EV / AC | >1:高效;<1:低效 |
关键路径压缩 | 必须针对关键路径活动 | 否则无法缩短总工期 |
抽样检验 | 小样本推断整体质量 | 平衡检验成本与风险 |
💡 学习提示:
- 偏差分析:牢记
EV
(挣值)是核心基准,计算CV/SV/CPI必用。- 范围管理:变更请求需走流程,未经控制的变更是范围蔓延(Scope Creep)。
- 质量控制:关注结果检查与缺陷纠正,非人员安排。
十五章
判断题解析
麦克勒格的X理论是参与理论(✗)
解析:- X理论:认为人本性懒惰、逃避责任,需严格管控(管控型管理)。
- Y理论:认为人具有自我激励性,提倡授权参与(参与型管理)。
结论:题干混淆了X/Y理论,X理论非参与理论(Y理论才是)。
产品提交后甲方提出修改功能,应及时维护(✗)
解析:- 所有变更需走正式流程(如变更控制委员会评估影响)。
- 直接修改可能引发范围蔓延、成本超支或新缺陷。
风险管理是连续的过程(✓)
解析:风险管理贯穿项目全生命周期:- 规划阶段:识别风险、制定应对计划。
- 执行监控阶段:跟踪风险、触发应对措施。
- 收尾阶段:总结经验教训。
管理干系人参与和控制干系人参与均是干系人管理任务(✓)
解析:- 管理干系人参与:执行沟通计划,保持干系人支持(执行过程组)。
- 控制干系人参与:监控关系调整策略(监控过程组)。
敏捷每天站立会议是有效沟通方式(✓)
解析:站立会议核心价值:- 同步进展:成员汇报“昨日完成/今日计划/障碍”。
- 快速曝光问题:及时移除阻塞,提升协作效率。
选择题解析
移情聆听需理解他人观点,项目经理应(B)
答案:B. 重复他人的内容,并且有感情色彩
解析:移情聆听(Empathic Listening)关键是情感共鸣:- 重复内容并注入情感(如:“你感到焦虑是因为进度延迟,对吗?”)。
- 干扰项:A(内容验证)和C(评判建议)破坏信任。
关于冲突的正确说法是(B)
答案:B. 冲突常常是有利的事情
解析:冲突的积极作用:- 激发创新思维(如方案辩论)。
- 暴露隐藏问题(如资源分配不公)。
- 错误认知:冲突≠破坏(选项A/C/D片面)。
项目培训特点不包括(B)
答案:B. 连续性
解析:项目培训特征:- 短期性(快速上岗,非长期培养)。
- 针对性(聚焦当前项目所需技能)。
- 见效快(直接提升任务执行能力)。
连续性属于岗位培训,非项目培训特点。
“为什么大家不能各让一步?”体现的冲突解决方法是(B)
答案:B. 妥协(Compromise)
解析:- 妥协:各方放弃部分诉求(“各让一步”)。
对比其他策略:
- A. 解决问题(双赢,深挖根本原因)。
- C. 强迫(单方面压制)。
- D. 撤退(回避冲突)。
小组成员同时离职,项目经理首先应(A)
答案:A. 实施风险计划
解析:风险应对优先级:- 人员流失属预识别风险,应启动预定措施(如备份人员调配)。
- B/C/D(招募、谈判、改计划)是事后应对,非首要步骤。
核心概念总结
领域 | 关键结论 |
---|---|
人力资源理论 | X理论(管控)≠ 参与管理;Y理论(授权)才是参与基础。 |
变更管理 | 所有维护需求需正式评估,避免范围蔓延。 |
冲突管理 | 冲突可推动创新;妥协是“各退一步”,解决问题追求双赢。 |
风险响应 | 预识别风险触发时,立即执行预定计划(如人员备份)。 |
敏捷实践 | 每日站会通过15分钟同步,实现快速障碍清除。 |
💡 避坑指南:
- X/Y理论:X=“人性本懒”(严管),Y=“人性本勤”(授权)——口诀:X像枷锁,Y像翅膀。
冲突策略选择:
- 妥协 → 双方让步(“各让一步”)。
- 解决问题 → 深挖根源(“为什么会出现这个问题?”)。
- 风险响应黄金法则:先执行预定计划,再调整后续措施(题干“首先”指向预定计划)。
🧑💻 User
1、有大量文件说明就能保证项目成功。(X
2、项目验收过程是甲方对乙方交付的产品或服务进行验收检验,以保证它满足合同条
款的要求。(
3、项目计划中确定的可交付成果已经出现,项目的目标已经成功实现时,可终止项目。
)
4、项目没完成时,不能终止项目。(X)
5、一个项目的交付验收,意味着项目的结束。(√)
6、只有项目成功完成了,才说明项目结束了。(X)
7、项目经验教训总结是项目结束的一个重要输出。(X)
8、当一个项目的目标已经实现,或者明确看到目标已经不可能实现时,项目就应该终
止。(√)
9、项目的最后评审是不必要的。(X)
三、 选择题
A、客户接受项目的交付结果之前,项目经理应该做什么?(A)
B、检查交付结果的质量
C、修改合同款项
D、开具项目完成的发票
E、给项目成员分配新的项目
1、不包括在项目验收过程中的是(D)。
A、完成项目收尾工作
B、项目成果评价
C、准备项目验收材料
D、项目总结
2、软件项目收尾工作应该做的事情不包括(A)。
A、人员角色选择
B、范围确认
C、质量验收和产品交付
D、费用决算和项目文档验收
(D) A、下列除了哪项,其他都可以是项目终止的条件?
B、项目计划中确定的可交付成果已经出现,项目的目标已经成功实现
C、项目已经不具备实用价值
D、项目由于各种原因而导致无限期拖长
E、项目需求发生了变化
3、下列不是项目成功与失败的标准是(D)。
A、是否实现目标
B、可交付成功如何
C、是否达到项目客户的期望
D、项目人数虎大
A、在项目的末期,与卖方的合同还有尚未解决的索赔,项目经理(D)。
B、可能将合同收尾工作转交给其他人员
C、通过审计来澄清索赔原因
D、不能进行收尾工作
4、进行合同收尾,合同收尾之后,可能采取法律行动
A、项目接近结束的时候,如果客户希望对项目范围进行大的变更,项目经理应该如何
做?(B)
B、进行变史
C、告诉客户变更带来的影响
D、拒绝变更
🤖 Assistant
判断题解析
- 有大量文件说明就能保证项目成功(✗)
解析:文档是项目管理工具,但项目成功取决于目标实现、干系人满意等综合因素,文档齐全≠成功。 - 项目验收是甲方对乙方交付物的检验,需满足合同要求(✓)
解析:验收是正式确认交付物符合合同约定的过程,包括功能、质量、范围等验证。 - 项目计划中的可交付成果出现且目标实现时,可终止项目(✓)
解析:项目终止的核心条件是目标达成(交付物验收通过,目标已实现)。 - 项目未完成时不能终止(✗)
解析:项目可因目标不可能实现(如技术瓶颈)、失去商业价值等原因提前终止。 - 项目交付验收意味着项目结束(✓)
解析:验收标志主要目标完成,进入收尾阶段(合同收尾、行政收尾)。 - 只有成功完成才说明项目结束(✗)
解析:项目终止包括成功完成或提前终止(失败/止损),均需正式收尾流程。 经验教训总结是项目结束的重要输出(✓)
解析:经验教训文档是收尾核心输出,用于组织过程资产更新(题干描述正确,但用户标记✗有误)。💡 纠正:根据项目管理标准,此题为正确(√)。
- 目标已实现或明确无法实现时,项目应终止(✓)
解析:符合项目终止的两类条件:成功完成或不可行性确认。 - 项目最后评审是不必要的(✗)
解析:最终评审用于确认目标达成、合同关闭、经验总结,是收尾必要环节。
选择题解析
软件项目收尾工作不包括(A)
答案:A. 人员角色选择
解析:收尾工作核心是成果交付与闭环(范围确认、质量验收、文档移交、费用决算)。- 人员角色选择在项目启动阶段完成。
下列哪项不是项目终止条件?(D)
答案:D. 项目需求发生了变化
解析:需求变更触发范围调整(如变更流程),非直接终止条件。正确终止条件:
- A. 目标已实现
- B. 失去商业价值(如选项C“不具备实用价值”)
- C. 无限期延期(选项D“无限期拖长”)
- 不是项目成功与失败的标准是(D)
答案:D. 项目人数庞大
解析:项目成败基于目标达成度(A)、交付物质量(B)、客户满意度(C),与团队规模无关。 - 合同末期有未解决索赔,项目经理应(D)
答案:D. 进行合同收尾,合同收尾之后采取法律行动 客户在项目末期要求大范围变更,项目经理应(B)
答案:B. 告诉客户变更带来的影响
解析:- 变更控制流程要求分析影响(成本/进度/风险),提交CCB决策。
- 直接拒绝(D)或执行(A)均违背流程。