2023年上半年系统集成项目管理工程师下午真题及答案解析.docxVIP

2023年上半年系统集成项目管理工程师下午练习题及答案解析

案例分析题一（范围管理与变更控制）

背景资料：某科技公司承接了某市政府“智慧社区综合管理平台”项目，合同约定工期6个月，预算300万元，主要建设内容包括基础数据平台开发、多部门数据接口对接、社区居民APP开发三大核心模块。项目启动后，用户方（街道办）在需求调研阶段提出新增“人脸识别门禁系统对接”功能，开发团队认为技术难度不高，未履行正式变更流程，仅与用户口头确认后直接修改开发计划。此后，用户又陆续提出“老年健康档案同步”“物业缴费功能嵌入”等5项小范围功能调整，开发人员为追赶进度，未记录变更内容及影响评估。项目执行3个月时，测试团队发现新增的“人脸识别门禁”模块与原有数据接口存在兼容性冲突，导致部分历史数据无法同步；用户方要求恢复部分旧功能，但开发文档缺失，需重新开发相关模块，最终项目延期1个半月，成本超支45万元。

问题1：结合案例，指出项目在范围管理过程中存在的主要问题。

答案：

（1）需求收集不完整、未确认：用户新增“人脸识别门禁”等功能时，未通过正式需求评审确认，仅口头沟通，导致需求边界模糊。

（2）未创建工作分解结构（WBS）：未将项目可交付成果分解为具体任务，无法有效监控范围变更对各模块的影响。

（3）范围控制缺失：多次功能变更未执行变更控制流程，未进行影响评估（如对进度、成本、质量的影响），开发人员直接修改代码，导致范围蔓延。

（4）确认范围未落实：测试阶段才发现新增功能与原有模块冲突，说明未在阶段末进行范围确认，未验证可交付成果是否符合用户需求。

解析：范围管理的核心是明确项目边界并控制变更。案例中，需求变更未通过正式流程（如变更申请单、影响分析、CCB审批），导致范围失控；同时，缺乏WBS分解和阶段确认，无法及时发现范围偏差。

问题2：分析案例中变更控制存在的主要不足。

答案：

（1）变更申请环节缺失：用户提出的功能变更未以书面形式提交，仅口头沟通，无法追溯变更来源和具体需求。

（2）变更评估不规范：开发团队未评估变更对进度（如新增功能需额外开发时间）、成本（增加人力投入）、质量（兼容性风险）的影响，导致后续返工。

（3）变更审批未执行：未由变更控制委员会（CCB）对变更的必要性、可行性进行审批，开发团队自行决定变更，缺乏高层决策支持。

（4）变更实施与监控缺位：变更执行过程中未记录修改内容，测试阶段发现问题时无文档可查，无法快速定位问题根源；变更后未跟踪验证效果。

解析：变更控制需遵循“申请评估审批实施监控关闭”的完整流程。案例中，变更仅停留在口头沟通，未进入正式流程，导致变更失控和后续返工。

问题3：针对案例中的问题，提出改进范围管理的具体措施。

答案：

（1）规范需求管理：采用原型法或用例分析完整收集需求，需求文档需经用户签字确认，作为范围基准。

（2）创建WBS：将项目可交付成果分解为具体任务（如“基础数据平台开发”分解为“数据库设计”“接口开发”等），明确每个任务的责任人和验收标准。

（3）严格变更控制流程：所有变更需提交书面变更申请，由CCB评估影响（如进度延迟2周、成本增加10万元），审批通过后更新范围基准，并通知所有相关方。

（4）加强阶段确认：每个开发阶段结束后，组织用户方进行可交付成果验收（如接口开发完成后测试数据同步效果），确认通过后方可进入下一阶段。

案例分析题二（进度管理与关键路径）

背景资料：某企业信息化升级项目包含以下活动（单位：周），活动间依赖关系如下：

活动A（需求调研）：3周，无前置活动；

活动B（系统设计）：4周，前置活动A；

活动C（硬件采购）：2周，前置活动A；

活动D（软件开发）：6周，前置活动B；

活动E（硬件部署）：3周，前置活动C；

活动F（集成测试）：5周，前置活动D、E；

活动G（用户培训）：2周，前置活动F。

问题1：绘制单代号网络图（节点图），并确定关键路径和总工期。

答案：

单代号网络图如下（节点为活动，箭线为依赖关系）：

A→B→D→F→G

A→C→E→F→G

关键路径为A→B→D→F→G，总工期=3+4+6+5+2=20周。

解析：关键路径是项目中最长的路径，决定总工期。计算各路径长度：

A→B→D→F→G：3+4+6+5+2=20周；

A→C→E→F→G：3+2+3+5+2=15周；

因此关键路径为前者，总工期20周。

问题2：若活动D（软件开发）因技术问题延迟3周完成，对项目总工期有何影响？说明理由。

答案：总工期将延迟3周。

理由：活动D位于关键路径上，其总浮动时间为0（关键活动无浮动时间）