2026年信息系统项目管理师(第二批次)案例分析考试试题及答案

2026年信息系统项目管理师（第二批次）案例分析考试试题及答案一、案例分析题一（25分）某省政务服务管理局拟建设“一网通办”升级改造项目，主要功能包括政务服务事项智能申报、电子证照共享、审批流程自动化等，项目总预算800万元，工期12个月。建设单位通过公开招标选定承建单位A公司，A公司任命技术骨干小李担任项目经理。小李上任后，基于之前做过的类似政务项目，快速编制了项目范围说明书，未与建设单位做详细确认就组织团队开始了需求分析和设计工作。项目实施过程中，建设单位的业务处室经常提出新的功能需求，小李为了维护客户关系，均直接安排开发团队进行调整，未做正式的记录和审批。项目进行到第6个月时，团队已完成的功能与最初约定的范围偏差较大，进度滞后约20%，成本超支15%。此时建设单位又提出接入省统一身份认证平台2.0版本的重大需求，小李评估后认为工作量不大，直接要求团队在1个月内完成开发，导致多名开发人员加班严重，核心开发人员提出离职，项目风险进一步加大。问题：1.请结合案例，指出该项目在范围管理和变更管理方面存在的主要问题。（10分）2.请简述项目范围基准的组成，以及变更控制委员会（CCB）的主要职责。（8分）3.阅读下列关于范围管理与变更管理的描述，判断正误（正确打√，错误打×，每题1分，共7分）。（1）项目范围基准包括批准的项目范围说明书、WBS和WBS词典。（2）所有的项目变更都必须经过变更控制委员会（CCB）的审批才能实施。（3）范围蔓延是指未对时间、成本和资源做相应调整的情况下，项目范围出现未经控制的扩大。（4）项目范围管理的主要目的是确保项目做且只做成功完成项目所需的全部工作。（5）变更申请只能由建设单位（客户）提出，项目承建方内部不能提出变更申请。（6）在敏捷项目中，因为需求是动态变化的，所以不需要进行范围控制。（7）控制范围过程是监督项目和产品的范围状态，管理范围基准变更的过程。答案：1.（10分，每答出1点得1分，最多10分）范围管理方面存在的问题：①未编制规范的范围管理计划，范围管理工作缺乏指导依据；②项目范围说明书未与建设单位详细确认，范围定义不清晰，未达成共识；③未建立工作分解结构（WBS）及WBS词典，范围基准不明确；④范围确认工作不到位，未及时对已完成的可交付成果进行阶段性验收；⑤未有效开展范围控制，未经控制的需求调整导致范围蔓延。变更管理方面存在的问题：①未建立规范的变更管理流程，变更未按程序执行；②未成立变更控制委员会（CCB），变更缺乏明确的审批主体；③需求变更未做正式记录和全面影响评估，就直接安排开发实施；④重大需求变更未走正式审批流程，项目经理擅自决定实施；⑤变更实施后未进行效果验证，也未同步更新范围、进度、成本等项目基准；⑥变更相关信息未及时告知所有干系人，沟通管理不到位。2.（8分）（1）范围基准的组成（3分）：范围基准是经过正式批准的项目范围说明书、工作分解结构（WBS）以及对应的WBS词典，是项目范围管理的基线，只有通过正式变更控制程序才能修改。（2）CCB的主要职责（5分，每答出1点得1分，最多5分）：①审议变更申请，评估变更对项目范围、进度、成本、质量等方面的影响；②审批变更申请，或作出否决变更的决定；③监督变更的实施过程，确认变更的交付结果符合要求；④协调变更相关的争议与冲突，保障变更有序推进；⑤定期评估变更的整体影响，确保变更符合项目的整体目标与商业价值。3.（7分，每题1分）（1）√（2）×（3）√（4）√（5）×（6）×（7）√解析：第3题易错点说明：（2）变更审批权限按变更的影响等级划分，minor级别的小额变更可由项目经理审批，重大变更才需提交CCB审批，并非所有变更都必须经CCB审批。（5）变更申请可由任何项目干系人提出，包括建设单位、承建方、监理单位、最终用户等。（6）敏捷项目同样需要范围控制，通过产品待办列表梳理、迭代规划、迭代评审等机制动态管理范围，避免未经控制的范围蔓延。二、案例分析题二（25分）某软件公司承接了一个企业ERP系统开发项目，项目经理根据项目需求分解得到8个活动，各活动的逻辑关系、计划工期、计划预算如下表所示：活动名称紧前活动计划工期（周）计划预算（万元）A-330BA440CA220DB330EB、C550FC220GD、E440HE、F330项目进行到第12周周末时，项目经理对项目绩效进行检查，得到如下数据：①活动A、B、C、F已全部完成，实际花费分别为32万元、38万元、21万元、19万元；②活动D已完成2周工作量，实际花费22万元；③活动E已完成3周工作量，实际花费36万元；④活动G、H尚未开始。假设各活动的成本按工期均匀投入，项目总预算（BAC）为所有活动计划预算之和。问题：1.请指出该项目的关键路径（用活动名称表示）和计划总工期。（6分）2.请计算项目进行到第12周周末时的计划值（PV）、挣值（EV）和实际成本（AC）。（10分）3.请计算第12周周末的成本绩效指数（CPI）和进度绩效指数（SPI），并分析项目当前的成本和进度绩效情况。（5分）4.假设项目当前的绩效是典型偏差，且后续工作仍按此绩效进行，请计算项目的完工估算（EAC）和完工尚需绩效指数（TCPI，基于BAC）。（4分）答案：1.（6分）关键路径：A→B→2.（10分）项目总预算BA（1）计划值（PV）：到第12周周末，计划完成的工作对应预算总和。根据活动计划，第12周周末应完成活动A、B、C、D、E、F，G、H尚未开始，因此：$$PV=30+40+20+30+50+20=190\text{万元}$$（3分）

（2）挣值（EV）：已完成工作的预算价值。

-活动A、B、C、F全部完成，贡献EV：$30+40+20+20=110$万元

-活动D完成2周工作量，贡献EV：$30\times\frac{2}{3}=20$万元

-活动E完成3周工作量，贡献EV：$50\times\frac{3}{5}=30$万元

-活动G、H未开始，贡献EV：0

因此总EV：

$$EV=110+20+30=160\text{万元}$$（4分）

（3）实际成本（AC）：已完成工作实际花费的总成本。

$$AC=32+38+21+19+22+36=168\text{万元}$$（3分）

3.（5分）

成本绩效指数：

$$CPI=\frac{EV}{AC}=\frac{160}{168}\approx0.95$$（2分）

进度绩效指数：

$$SPI=\frac{EV}{PV}=\frac{160}{190}\approx0.84$$（2分）

绩效分析：$CPI<1$，说明项目当前成本超支；$SPI<1$，说明项目当前进度滞后。（1分）

4.（4分）

典型偏差下，完工估算：

$$EAC=\frac{BAC}{CPI}=\frac{260}{160/168}=273\text{万元}$$（2分）

基于BAC的完工尚需绩效指数：

$$TCPI=\frac{BAC-EV}{BAC-AC}=\frac{260-160}{260-168}=\frac{100}{92}\approx1.09$$（2分）

**解析**：

本题考查进度网络分析与挣值管理的结合应用，核心要点：

1.关键路径是总工期最长的路径，决定项目的最短完成时间，路径上活动的总时差为0；

2.挣值计算需严格区分PV（计划工作量的预算）、EV（已完成工作量的预算）、AC（已完成工作量的实际花费）三个核心指标的定义；

3.典型偏差指当前偏差是未来工作的典型代表，后续绩效与当前一致，因此EAC用BAC除以CPI计算；

4.TCPI表示为了按预算完成项目，剩余工作需要达到的成本绩效水平，大于1说明剩余工作绩效要求高于当前水平，难度较大。

##三、案例分析题三（25分）

某互联网公司承接了一个社区团购平台的研发项目，项目周期6个月，需求变化较快，公司决定采用Scrum敏捷开发模式。公司任命有5年传统项目管理经验的张工担任ScrumMaster，团队共8名成员，包括5名开发、2名测试、1名UI设计师。

项目启动后，张工按照传统项目的习惯，编制了详细的项目进度计划和需求规格说明书，并要求团队严格按照计划执行。产品负责人由于同时负责多个产品，经常无法参加迭代评审会，每次迭代的需求排序都是张工直接决定。团队成员经常被公司抽调去支持其他紧急项目，迭代内经常出现人员不足的情况。

在第一次迭代中，市场部门提出了一个新的营销功能需求，张工认为需求合理，直接安排开发人员加入当前迭代的开发任务中，导致迭代结束时原计划的10个故事点只完成了4个，迭代失败。每日站会上，张工要求每个成员向他汇报工作进展和遇到的问题，会议经常持续40分钟以上，团队成员普遍感到疲惫和不满。

项目进行到第2个迭代时，团队士气低落，交付速率持续下降，产品负责人对交付成果不满意，项目面临延期风险。

问题：

1.请结合案例，指出该项目在Scrum敏捷实施过程中存在的主要问题。（12分）

2.请简述Scrum框架的三个工件和五个事件分别是什么。（8分）

3.请结合案例，说明敏捷项目中应对需求变更的主要措施。（5分）

**答案**：

1.（12分，每答出1点得1分，最多12分）

①ScrumMaster角色定位错误，仍采用传统项目管理思维，未履行服务型领导、团队赋能的职责；

②错误地编制详细的长期进度计划和固定需求规格说明书，不符合敏捷迭代式、增量式开发的特点；

③产品负责人职责缺位，经常缺席迭代评审会，未履行产品待办列表维护、需求排序的核心职责；

④需求排序由ScrumMaster越权决定，违反Scrum中产品负责人负责优先级排序的规则；

⑤团队成员不稳定，经常被抽调支持其他项目，违反了敏捷团队稳定、跨职能的原则；

⑥迭代内随意增加新需求，破坏了迭代时间盒，是迭代失败的直接原因；

⑦每日站会定位错误，变成向领导汇报的会议，而非团队成员同步进展、自组织调整的会议；

⑧每日站会严重超时，违反了Scrum每日站会不超过15分钟的规则；

⑨未按要求召开迭代回顾会议，没有及时总结迭代问题、持续改进过程；

⑩迭代规划不合理，未结合团队实际交付速率确定迭代任务量；

⑪需求变更流程不规范，市场部门的需求未通过产品负责人进入产品待办列表，直接插入迭代；

⑫团队沟通机制不畅，ScrumMaster未及时清除团队障碍，导致士气低落、效率下降；

⑬未建立明确的完成定义（DoD），迭代交付成果的质量缺乏统一标准。

2.（8分）

（1）三个工件（3分，每个1分）：

①产品待办列表（ProductBacklog）：有序的需求清单，包含产品所需的所有功能、特性、改进等，由产品负责人负责维护和排序，是迭代需求的来源。

②迭代待办列表（SprintBacklog）：从产品待办列表中选取的、当前迭代要完成的工作项集合，还包括交付增量的计划，由开发团队拥有。

③产品增量（Increment）：迭代结束时完成的所有产品待办列表项的总和，是可工作、可发布的产品版本，必须满足团队约定的完成定义（DoD）。

（2）五个事件（5分，每个1分）：

①冲刺（Sprint）：固定时长的时间盒（通常1~4周），在其中交付可发布的产品增量，是Scrum的核心迭代单元。

②冲刺规划会议（SprintPlanning）：冲刺开始时召开，确定冲刺目标和迭代待办列表。

③每日站会（DailyScrum）：每天召开的15分钟短会，团队同步进展、识别障碍、调整当日工作。

④冲刺评审会议（SprintReview）：冲刺结束时召开，展示完成的产品增量，收集干系人反馈，调整产品待办列表。

⑤冲刺回顾会议（SprintRetrospective）：冲刺评审后、下一个冲刺规划前召开，团队总结迭代过程中的经验教训，持续改进。

3.（5分，每答出1点得1分，最多5分）

①采用迭代式开发，将需求变更放在迭代之间进行调整，严格遵守迭代时间盒，迭代内一般不接受新需求；

②由产品负责人统一管理需求，所有新增需求先进入产品待办列表，按优先级排序后纳入后续迭代；

③通过迭代评审会议定期收集干系人反