信息系统项目管理师案例分析当天每日一练试题地址：www.cnitpm.com/exam/ExamDayAL.aspx?t1=1

往期信息系统项目管理师每日一练试题汇总：www.cnitpm.com/class/27/e1_1.html

信息系统项目管理师案例分析每日一练试题（2026/6/10）在线测试：www.cnitpm.com/exam/ExamDayAL.aspx?t1=1&day=2026/6/10

点击查看：更多信息系统项目管理师习题与指导

信息系统项目管理师案例分析每日一练试题内容（2026/6/10）

试题一（25分）
阅读下列说明，回答问题1至问题4，将解答填入答题纸的对应栏内.
【说明】
某集团公司希望对总部现有信息系统进行升级改造，升级后的系统能收集整合子公司各类数据，实现总部对全集团人力资源、采购、销售信息的掌握、分析及预测。
小王担任项目经理，项目交付期为60天。小王研究了总部提出的需求后，认为项目核心在于各子公司数据收集以及数据可视化及分析预测功能。各子公司数据收集可以以总部现有系统中的数据格式模板为基础，为各子公司建立数据上传接口。针对数据的分析预测功能，由于涉及到人工智能等相关算法。目前项目组还不具备相关方面的知识储备，因此项目组对该模块功能直接外包。小王将数据收集与可视化工作进行了WBS分解，WBS的部分内容如下∶

此外，虽然总部没有提出修改界面，但小王认为旧版的软件界面不够美观，让软件研发团队重新设计并更改了软件界面。
试运行阶段，总部人员试用后，认为已经熟悉旧版的操作模式，对新版界面的布局极其不适应；各子公司数据报送人员，认为数据上报的字段内容与自己公司的业务并不相关，填写困难。总部和各子公司的试用人员大部分认为新系统不是很好用。
【问题1】（12分）
（1）请结合案例，简要分析该项目经理在WBS分解中存在的问题。
（2）写出WBS分解时，需要注意的事项。
【问题2】（8分）
请结合案例，除WBS分解的问题外，项目在范围管理中还存在哪些问题。
【问题3】（3分）
请描述项目范围说明书的内容。
【问题4】（2分）
请将下面（1）～（4）处的答案填写在答题纸的对应栏内。
项目范围是否完成要以（1）来衡量，包括（2），（3），（4）。

信管网cnit**************：
（1） 1.未确认全部可交付成果 2.未进行收集需求 3.团队成员未参与整个过程 4.wbs未包含所有可交付成果 5.外包工作未计算在wbs内 6.未确认范围，导致范围蔓延 7.没有与主要干系人沟通和确认 8.未进行整体变更控制 （2） 1.wbs必须面向可交付成果 2.wbs必须符合项目范围 3.wbs分解4-6层 4.wbs元素必须有一人负责 5.wbs底层工作包必须支持计划和控制 6.wbs分解必须所有干系人参与 7.wbs工序必须包括项目管理工作 8.wbs并非一成不变的1.没做收集需求 2.没确认项目范围 3.没做变更控制，范围蔓延 4.没做好干系人沟通 5.项目范围交付成果未确认评审项目范围 产品范围描述 主要可交付成果 假设条件 制约因素 验收标准 项目除外责任1验收并上线 2验收的可交付成果 3产品文档 4产品手册

信管网软考高项****：
1.程序编制总工期为30天，下属活动包却是65天，不符合分解要求 2.系统测试验收工作由多人负责，不符合唯一责任人原则 3.子模块综合大于了总工期，不符合分解规则 4.赵工同时负责了销售模块和采购模块，存在资源紧张或冲突的问题 5.人力资源模块分解时长超过了80小时原则 注意事项： 1.分解工作支持100％的项目工作原则 2.工作包由唯一的负责人 3.下级元素之和等于上级元素 4.分解层级为4-6层 5.单活动包的小时不超过80小时原则 6.wbs并非一成不变的 7.分解层级支持项目工作的控制和管理 1.缺少范围管理计划和需求管理计划 2.获取需求从现有数据为进行有效的需求调研分析 3.定义范围工作不够全面客观，缺少干系人参与 4.控制范围缺少变更管理控制流程进行管控 5.未制定客观全面的范围基准 6.确认范围工作存在不足，未进行有效的范围确认便试用 7.未制定客观全面的验收标准1.除外责任 2.项目工作 3.产品工作 4.验收标准1.范围基准 2.wbs 3.wbs词典 4.范围工作说明书

信管网loom**：
（1）①没有完全分解全部任务，缺少外包的数据预测功能模块的wbs分解；②在分解wbs时，自行把软件界面修改加入到需求，扩大了范围，增加了项目风险；③wbs分解没有把系统测试与验收这个任务分解到最小工作包，该任务的负责人应该为一个人，不该由两人负责。 （2）wbs分解要注意将每个任务分解到最小工作包，每个工作包只能有一个负责人，wbs分解不要扩大需求范围，要按照项目范围计划合理分解。1.自行扩大了项目范围 2.收集需求工作没有做好，导致数据上报字段与业务衔接不上。 3.范围变更没有提交变更申请，随意变更范围，增大风险需求功能，需求收集技术，范围确认标准确认范围过程，需求跟踪矩阵，需求文件，项目章程

信管网liao********：
违反 100％ 原则，范围严重遗漏 项目核心包含子公司数据收集和ai 分析预测两大模块。但 wbs 仅分解了数据收集与可视化工作，完全未纳入外包的人工智能分析预测模块，且遗漏了子系统接口开发、系统集成、项目管理、培训、运维支持等大量必要工作，导致范围缺失。 wbs 结构逻辑混乱（层级错误） 案例中显示，“程序编制（3）” 下面直接列出了 “人力资源模块编码（3.2.1）” 等子任务。逻辑错误：“系统设计（2）” 应先于 “程序编制（3）” 进行，且 “模块编码” 应属于 “程序编制” 下的具体工作，wbs 的层级结构颠倒，结构不清晰。 父任务与子任务工期逻辑矛盾 父任务 “程序编制（3）” 工期仅 30 天，但其下两个子任务 “人力模块编码（25 天）”+“销售模块编码（20 天）” 工期总和已达 45 天，子任务工期超过父任务，违反了 wbs “上层包含下层” 的逻辑，无法用于工期管控。 发生范围镀金（gold plating） 案例提到 “小王认为旧版界面不够美观，让团队重新设计并更改了软件界面”，这属于未经变更控制流程批准、超出原计划范围的工作，违反了范围控制原则，导致系统上线后水土不服。 分解粒度不均，未按可交付成果分解 wbs 仅按软件开发阶段（设计、编制、测试）分解，未按可交付成果（如人力资源系统、采购系统、销售系统）分解，不利于按子公司交付物进行责任分配和管理。 遵循 100％ 原则 wbs 必须包含项目 100％ 的所有工作，既不能遗漏必要工作，也不能包含无关工作（即下层之和必须严格等于上层）。 面向可交付成果 分解应以可交付成果为导向，而不是仅按部门或时间阶段分解。每个组件都必须是有形的、可验证的交付物。 层级清晰且适度 分解应结构清晰，父子层级关系明确。分解层级建议控制在4-6 层，避免过细增加管理成本。 工作包粒度符合 8/80 原则 wbs 最底层（工作包）的工作量应控制在8 小时至 80 人天之间，便于项目经理进行工期、成本和责任的精细化管理。 确保独立性与可管理性 每个工作包应有明确的负责人和独立的交付物，且能独立进行进度、成本核算，不可与其他工作包混淆。 包含项目管理工作 wbs 必须包含项目管理相关需求调研不充分、范围镀金、变更无流程、未做范围确认、外包管理缺失，产品范围描述：详细描述项目要交付的产品、服务或成果的特性、功能、技术要求等。 项目范围描述：明确项目包含的所有工作、可交付成果，以及项目的边界（哪些工作不属于项目范围）。 项目的主要可交付成果：列出项目最终要交付的核心成果，作为验收的依据。 项目的制约因素与假设条件：记录项目的进度、成本、资源等约束，以及项目执行的前提假设。 项目的验收标准：明确可交付成果的验收标准、验收流程、验收时间等。 项目的除外责任：明确说明哪些工作不属于项目范围，避免范围蔓延。（1） 项目范围基准 （2） 项目范围说明书 （3） 工作分解结构（wbs） （4） wbs 词典

信管网威武的橙*****：
1.在创建wbs前只研究了总公司需求，但是未向其他干系人收集相关需求，没有确保所有干系人参与，导致需求不够全面。 2.外包部分的工作未列入wbs工作包内 3.系统设计没有列出具体的可交付工作包 1.需要所有干系人参与 2.分层4-6层最佳 3.应该由整个项目团队参与制定 1.对界面的更改，未收到相关需求，但是私自进行更改，导致需求蔓延的同时，还没有收到好的反馈，导致产生不一致成本 2.收集需求过程中，未对其他工作人员的需求进行收集，导致产品不符合工作需要 3.对于人工智能方面的外包，未通过高层领导的决策，可能会导致到期无法交付等风险。质量