《信息系统项目管理师》案例分析题及解析模拟题8

《信息系统项目管理师》案例分析题及解析模拟题8

总体概况与考试技巧

案例分析题共 3 道试题，围绕信息系统项目管理的核心领域展开，分别聚焦范围管理、进度与成本管理、配置与质量管理，每题 25 分，总分 75 分。题目均以实际项目场景为背景，通过呈现项目执行中的问题，考查对理论知识的应用能力，重点涉及 WBS 分解、范围基准、单代号网络图、配置变更流程等高频考点。

考试技巧方面，需把握以下 3 点：

1. 审题优先：先通读案例说明，标记关键信息（如时间、角色、问题现象），再对应问题定位案例中的相关描述，避免脱离场景空谈理论。
2. 逻辑分层：回答 “问题分析类” 题目时，按 “问题表现 - 理论依据 - 案例对应” 的逻辑组织答案；回答 “流程 / 内容类” 题目时，直接按教材规范框架罗列，确保要点全面。
3. 计算细心：涉及 PV、EV、AC 等成本绩效指标计算时，先明确计算周期和数据来源（如每月预算、任务完成率），步骤清晰呈现，避免因数据提取错误导致结果偏差。

试题一（25 分）

阅读下列说明，回答问题 1 至问题 4，将解答填入答题纸的对应栏内。

【说明】

某集团公司希望对总部现有信息系统进行升级改造，升级后的系统能收集整合子公司各类数据，实现总部对全集团人力资源、采购、销售信息的掌握、分析及预测。

小王担任项目经理，项目交付期为 60 天。小王研究了总部提出的需求后，认为项目核心在于各子公司数据收集以及数据可视化及分析预测功能。各子公司数据收集可以以总部现有系统中的数据格式模板为基础，为各子公司建立数据上传接口。针对数据的分析预测功能，由于牵涉到人工智能等相关算法，目前项目组还不具备相关方面的知识储备，因此项目组对该模块功能直接外包。小王将数据收集与可视化工作进行了 WBS 分解，WBS 的部分内容如下：

工作编号	工作任务	工期	负责人
\* \* \*
2	系统设计	20 天	王工厂
3	程序编制	30 天	任工
3.2.1	人力资源模块编码	25 天	孙工
3.2.2	采购模块编码	20 天	赵工
3.2.3	销售模块编码	20 天	赵工
###		###
4	系统测试与验收	5 天	张工、李工

此外，虽然总部没有提出修改界面，但小王认为旧版的软件界面不够美观，让软件研发团队重新设计并更改了软件界面。

试运行阶段，总部人员试用后，认为已经熟悉旧版的操作模式，对新版界面的布局极其不适应；各子公司数据报送人员，认为数据上报的字段内容与自己公司的业务并不相关，填写困难。总部和各子公司的试用人员大部分认为新系统不是很好用。

【问题 1】（12 分）

（1）请结合案例，简要分析该项目经理在 WBS 分解中存在的问题。

（2）写出 WBS 分解时，需要注意的事项。

【参考答案】

1. WBS 分解存在的问题：
   • 工作包负责人设置违规，4 号 “系统测试与验收” 由张工、李工多人负责，不符合 “一个工作单元仅一人负责” 的原则。
   • WBS 编制参与方单一，仅由小王单独负责，未组织主要项目干系人（如子公司代表、项目团队成员）参与，导致需求覆盖不全。
   • 工作工期逻辑矛盾，3 号 “程序编制” 总工期 30 天，但其下分解的 3.2.1-3.2.3 任务工期累加（25+20+20=65 天）远超总工期，不符合分解逻辑。
   • 总工期超出计划，现有分解任务（系统设计 20 天 + 程序编制 30 天 + 测试 5 天 = 55 天，未含其他未列出任务）已接近或超过 60 天交付期，未预留缓冲时间。
   • 外包工作未纳入 WBS，数据的分析预测功能虽外包，但未在 WBS 中体现，导致范围遗漏。
   • 未遵循 8/80 原则，多数工作包工期（如系统设计 20 天、程序编制 30 天）超过 80 小时（约 10 个工作日），分解过粗，不利于进度控制。
   • 部分工作未进一步分解，2 号 “系统设计” 未拆解为更细的工作单元（如需求分析、架构设计），无法支撑具体执行。
   • 缺失项目管理工作，WBS 中未包含进度管理、质量管理等项目管理类工作包，不符合 “WBS 需覆盖全部项目工作” 的要求。
   • 分解层级不足，现有 WBS 仅到 3.2.x 层级，未达到 4-6 层的合理范围，颗粒度不够细致。

1. WBS 分解的注意事项：
   • 面向可交付成果，分解需围绕项目最终产品 / 服务，而非单纯罗列活动。
   • 符合项目范围，仅包含完成可交付成果所需的工作，不遗漏、不超出。
   • 底层支撑计划与控制，WBS 底层工作包需能明确工期、成本、负责人，便于进度和预算监控。
   • 责任唯一，每个工作单元仅由一人负责，避免多人共管导致责任不清。
   • 控制分解层级，通常为 4-6 层，大项目可适当增加，且工作单元不可交叉从属。
   • 包含全部工作，需覆盖项目管理工作及外包工作，确保范围完整。
   • 多方参与编制，组织主要干系人（如客户、团队成员）共同编制，确保需求一致。
   • 保持动态调整，WBS 并非固定不变，需根据项目变更及时更新。

【问题 2】（8 分）

请结合案例，除 WBS 分解的问题外，项目在范围管理中还存在哪些问题。

【参考答案】

• 未制定范围管理计划，未明确范围定义、确认、控制的流程和方法，导致范围管理无序。
• 需求收集不完整，仅收集总部需求，未调研子公司对数据上报字段的需求，导致子公司使用困难。
• 需求未确认，收集的需求未经过总部、子公司等干系人签字确认，导致需求共识不足。
• 缺失需求文档与跟踪矩阵，未形成书面需求文件，也未建立需求与可交付成果的跟踪关系，无法验证需求是否实现。
• 未定义项目范围，未编制项目范围说明书，且未通过评审获得批准，导致范围基准缺失。
• 无范围变更流程，小王擅自决定修改软件界面（镀金），未走变更申请、审批流程，超出原定范围。
• 范围控制不力，未及时发现并纠正 “界面修改”“字段不匹配” 等范围偏差，导致最终成果不符合用户预期。
• 范围确认未执行，试运行阶段未按流程组织干系人进行范围确认（验收），无法及时发现问题并调整。

【问题 3】（3 分）

请描述项目范围说明书的内容。

【参考答案】

• 产品范围描述：明确项目最终交付的产品 / 服务的功能、特性（如系统需实现子公司数据收集、总部数据分析预测）。
• 验收标准：规定可交付成果的验收条件（如系统试运行无重大故障、数据上报准确率达 95%）。
• 可交付成果：列出项目需交付的具体成果（如数据上传接口、数据可视化报表、系统测试报告）。
• 项目的除外责任：明确项目不包含的工作（如不负责子公司现有系统的硬件升级）。
• 项目的制约因素：影响项目执行的限制条件（如 60 天交付期、现有系统数据格式约束）。
• 假设条件：项目执行的前提假设（如子公司会配合提供数据格式需求、外包团队按时交付分析模块）。

【问题 4】（2 分）

请将下面（1）~（4）处的答案填写在答题纸的对应栏内。

项目范围是否完成要以（1）来衡量，包括（2）、（3）、（4）。

【参考答案】

（1）范围基准 （2）批准的项目范围说明书 （3）WBS （4）WBS 字典

试题二（25 分）

阅读下列说明，回答问题 1 至问题 4，将解答填入答题纸的对应栏内。

【说明】

某项目的任务计划表如表 1 所示，资金计划和资金使用情况表如表 2。

项目完成后得到任务完成情况月报表如表 3 所示。

表 1 任务计划表

序号	包	任务	紧前任务	人数	计划工期（月）	计划任务完成率安排
						1 月
1	包 A	任务 1	-	4	2	50%
2	包 A	任务 2	任务 1	2	1	-
3	包 B	任务 3	任务 2	1	1	-
4	包 B	任务 4	-	4	2	50%
5	包 B	任务 5	任务 1、4	3	3	-
6	包 C	任务 6	任务 3	2	2	-
7	包 C	任务 7	任务 3	2	2	-
8	包 D	任务 8	任务 1、4	2	3	-
9	包 D	任务 9	任务 5、8	1	1	-

（注：计划任务完成率：某任务当月计划完成量与该任务全部工作量的比值）

表 2 资金计划和资金使用情况表（单位：万元）

时间（月）	总预算计划执行	总预算实际执行	财政资金预算计划执行	财政资金预算实际执行	自筹资金预算计划执行	自筹资金预算实际执行
1 月	400	200	200	0	200	200
2 月	700	700	300	100	400	600
3 月	1100	1700	100	100	1000	1600
4 月	2700	3800	600	1000	2100	2800
5 月	2300	1400	400	400	1900	1000
6 月	1800	1400	500	500	1300	900
累计	9000	9200	2100	2100	6900	7100

表 3 任务完成情况表

序号	包	任务	计划工期（月）	实际任务完成率
				1 月
1	包 A	任务 1	2	60%
2	包 A	任务 2	1	-
3	包 B	任务 3	1	-
4	包 B	任务 4	2	50%
5	包 B	任务 5	3	-
6	包 C	任务 6	2	-
7	包 C	任务 7	2	-
8	包 D	任务 8	3	-
9	包 D	任务 9	1	-

（注：实际任务完成率：某任务当月实际完成量与该任务全部工作量的比值）

【问题 1】（4 分）

请根据项目任务计划表，绘制项目的单代号网络图。

【参考答案】

（注：单代号网络图以节点表示任务，箭线表示紧前关系，节点内标注任务名称、持续时间（月）、人数）

• 起点节点：任务 1（持续 2 月，4 人）、任务 4（持续 2 月，4 人）
• 任务 2（持续 1 月，2 人）：紧前节点为任务 1
• 任务 3（持续 1 月，1 人）：紧前节点为任务 2
• 任务 5（持续 3 月，3 人）：紧前节点为任务 1、任务 4
• 任务 8（持续 3 月，2 人）：紧前节点为任务 1、任务 4
• 任务 6（持续 2 月，2 人）：紧前节点为任务 3
• 任务 7（持续 2 月，2 人）：紧前节点为任务 3
• 任务 9（持续 1 月，1 人）：紧前节点为任务 5、任务 8
• 终点节点：任务 6、任务 7、任务 9

【问题 2】（7 分）

（1）项目参与人员均可胜任任意一项任务，请计算项目每月需要的人数，并估算项目最少需要多少人？

（2）项目经理希望采用资源平滑的方式减少项目人员，请问该方法是否可行？为什么？

【参考答案】

1. 每月所需人数及最少人数：
   • 1 月：任务 1（4 人）+ 任务 4（4 人）=8 人
   • 2 月：任务 1（4 人）+ 任务 4（4 人）=8 人
   • 3 月：任务 2（2 人）+ 任务 5（3 人）+ 任务 8（2 人）=7 人
   • 4 月：任务 3（1 人）+ 任务 5（3 人）+ 任务 8（2 人）=6 人
   • 5 月：任务 5（3 人）+ 任务 6（2 人）+ 任务 7（2 人）+ 任务 8（2 人）=9 人
   • 6 月：任务 6（2 人）+ 任务 7（2 人）+ 任务 9（1 人）=5 人
   • 项目最少需要 9 人（5 月为人数需求峰值，需满足该月人员配置）。

1. 资源平滑方式不可行，原因：资源平滑仅适用于非关键路径任务，通过调整非关键路径的工期来平衡资源需求；而本项目中所有任务均在关键路径上（无自由浮动时间），无法通过资源平滑调整，因此该方法不可行。

【问题 3】（5 分）

项目第 1 个月月底时，项目经理考察项目的执行情况，请计算此时项目的 PV、EV 和 AC。

【参考答案】

• PV（计划值）：1 月总预算计划执行额 = 400 万元
• EV（挣值）：1 月各任务实际完成工作量对应的预算值 = 1 月总预算计划执行额 ×（任务 1 实际完成率 + 任务 4 实际完成率）=400×（60%+50%）=440 万元
• AC（实际成本）：1 月总预算实际执行额 = 200 万元

【问题 4】（9 分）

项目第 2 个月月底时，上级部门考核财政资金使用情况，请给出项目此时的执行绩效。

【参考答案】

1. 财政资金使用情况：2 月累计财政资金预算计划执行 = 1 月 200 万元 + 2 月 300 万元 = 500 万元；2 月累计财政资金实际执行 = 1 月 0 万元 + 2 月 100 万元 = 100 万元，财政资金执行节约。
2. 项目整体绩效指标计算：
   • PV（计划值）：1-2 月总预算计划执行累计 = 400+700=1100 万元
   • AC（实际成本）：1-2 月总预算实际执行累计 = 200+700=900 万元
   • EV（挣值）：1-2 月各任务实际完成工作量对应的预算值 = 1-2 月总预算计划执行累计 ×（任务 1 实际完成率 + 任务 4 实际完成率）=1100×（60%+40%+50%+50%）=1100×200%？ 修正：EV=（任务 11 月完成 60%× 任务 1 预算占比 + 任务 12 月完成 40%× 任务 1 预算占比）+（任务 41 月完成 50%× 任务 4 预算占比 + 任务 42 月完成 50%× 任务 4 预算占比），因 1-2 月总预算计划执行 1100 万元，且任务 1、4 为 1-2 月唯一执行任务，实际完成率均为 100%（任务 1：60%+40%=100%；任务 4：50%+50%=100%），故 EV=1100×100%=1100 万元。

1. 绩效结论：
   • 成本偏差 CV=EV-AC=1100-900=200 万元＞0，成本节约。
   • 进度偏差 SV=EV-PV=1100-1100=0 万元，进度正常。

试题三（25 分）

阅读下列说明，回答问题 1 至问题 4，将解答填入答题纸的对应栏内。

【说明】

某公司中标医院的信息管理系统，公司指派小王担任项目经理，并组建相应的项目团队。由于人手有限，小王让负责项目质量工作的小杨同时担当配置管理员。小杨编写并发布了质量管理计划和配置管理计划。

小杨利用配置管理软件对项目进行配置管理，为了项目管理方便，小杨给小王开放所有的配置权限，当有项目组成员提出配置变更需求时，小杨直接决定是否批准变更请求。小杨为项目创建了三个文件夹，分别作为存放开发、受控、产品文件的目录，对经过认定的文档或经过测试的代码等能够形成配置基线的文件，存放到受控库中，并对其编号。项目研发过程中，某软件人员打算对某段代码作一个简单修改，他从配置库检出待修改的代码段，修改完成并经测试没问题后，检入配置库，小杨认为代码改动不大，依然使用之前的版本号，并删除了旧的代码。公司在质量审计过程中，发现项目管理方面的诸多问题。

【问题 1】（10 分）

请结合案例，简要分析该项目在配置管理方面存在的问题。

【参考答案】

• 配置管理员兼职不合理，由质量管理人员小杨兼职配置管理员，可能因缺乏配置管理专业经验导致流程疏漏。
• 未成立配置管理委员会（CCB），缺少变更决策的核心组织，导致变更审批无集体决策机制。
• 配置管理计划未经审批，小杨编写的配置管理计划直接发布，未通过 CCB 或干系人评审，不符合规范。
• 配置库权限设置违规，给项目经理小王开放所有配置权限，易导致权限滥用，破坏配置库安全性。
• 变更控制流程缺失，小杨直接决定变更批准与否，未执行 “变更申请 - 评估 - 审批 - 实施 - 验证” 的规范流程。
• 版本管理不规范，代码修改后未更新版本号，且删除旧版代码，不符合 “版本迭代保留历史版本” 的原则，无法追溯变更。
• 未编制配置状态报告，未定期向干系人反馈配置项的变更情况、版本状态，导致信息不透明。
• 未开展配置审计，未通过配置审计验证配置项的完整性、一致性，无法及时发现配置管理中的问题。

【问题 2】（8 分）

请结合案例，描述在软件升级过程中的配置库变更控制流程。

【参考答案】

1. 基线取出：将待升级的软件配置基线（如需修改的代码）从产品库中取出，放入受控库，确保修改基于正式基线。
2. 代码检出：开发人员从受控库中检出待修改的代码段，此时系统对该代码段 “锁定”，防止其他人员同时修改。
3. 变更申请：开发人员完成代码修改并测试后，提交配置变更申请，说明变更内容、原因、影响范围，提交至 CCB。
4. 变更评估与审批：CCB 对变更申请进行评估（如技术可行性、成本影响），形成审批意见（批准 / 驳回）。
5. 代码检入：变更获批后，开发人员将修改后的代码检入受控库，系统解除 “锁定”，并自动分配新的版本号（如 V1.1→V1.2）。
6. 基线更新：若变更影响配置基线，需在受控库中更新基线版本，并记录变更日志，保留旧版基线供追溯。
7. 配置验证：配置管理员（小杨）验证检入的代码与变更申请的一致性，确保修改符合要求。
8. 状态报告：将本次变更的版本、内容、审批结果纳入配置状态报告，同步给相关干系人。

【问题 3】（5 分）

请简述质量审计的目标。

【参考答案】

• 识别良好实践：发现项目中正在实施的有效管理方法（如规范的测试流程），便于推广。
• 识别问题与不足：找出项目在流程执行、文档管理等方面的违规做法（如配置变更未审批），明确改进方向。
• 分享行业经验：将组织或行业内类似项目的最佳实践分享给项目团队，提升管理水平。
• 改进过程执行：主动提供协助，指导项目团队优化管理流程（如完善配置变更流程），提高生产效率。
• 积累经验教训：将审计发现的问题及解决方案记录存档，为后续项目提供参考，避免重复犯错。

【问题 4】（2 分）

在候选答案中选择正确选项，将该选项的编号填入答题纸内。

通常来说，质量管理人员不应具备（ ）的权限。

A. 产品库代码的 Check 权限

B. 产品库文档的 Check 权限

C. 受控库代码的 Check 权限

D. 受控库文档的 Check 权限

【参考答案】

A、C