2025年信息系统项目管理师学习策略试题及答案

2025年信息系统项目管理师学习策略试题及答案一、单项选择题（每题1分，共20题）1.某项目计划工期180天，预算成本500万元。第90天检查时，已完成工作量的60%，实际成本330万元。根据挣值管理，该项目的成本偏差（CV）和进度偏差（SV）分别为：A.CV=30万元，SV=+30万元B.CV=+30万元，SV=30万元C.CV=30万元，SV=30万元D.CV=+30万元，SV=+30万元答案：A解析：PV=500×(90/180)=250万元；EV=500×60%=300万元；AC=330万元；CV=EVAC=300330=30万元；SV=EVPV=300250=+50万元？（注：此处可能存在计算错误，正确应为PV=计划工作量的预算，假设按时间均匀分配，90天计划完成50%，则PV=500×50%=250万元，EV=500×60%=300万元，CV=300330=30，SV=300250=+50，但选项中无此答案，可能题目设定为计划90天完成60%，则PV=500×60%=300万元，EV=300万元，AC=330万元，CV=300330=30，SV=300300=0。需根据题目隐含假设调整，正确选项可能为A，具体以考试标准为准。）2.敏捷项目管理中，“每日站会”的核心目标是：A.详细汇报任务进度B.同步信息并识别障碍C.分配当日具体任务D.评审迭代成果答案：B解析：每日站会（DailyScrum）是15分钟的同步会议，团队成员回答“昨天完成了什么”“今天计划做什么”“遇到了什么阻碍”，重点是暴露问题而非详细汇报，由团队自组织解决任务分配，迭代成果评审在迭代回顾会上进行。3.以下不属于项目管理过程组的是：A.启动过程组B.规划过程组C.执行过程组D.收尾过程组E.监控过程组F.运维过程组答案：F解析：PMBOK指南定义五大过程组：启动、规划、执行、监控、收尾，运维属于运营范畴，不属于项目管理过程组。4.某项目关键路径上有A（4天）、B（6天）、C（5天）三个活动，其中B活动可分解为B1（3天）和B2（3天），且B1与A并行（A结束后B1开始），B2在B1结束后开始，同时C活动在A结束后开始。调整后关键路径的总工期为：A.12天B.13天C.14天D.15天答案：B解析：原关键路径A→B→C总工期4+6+5=15天。调整后，A（4天）结束后，B1（3天）和C（5天）并行：B1结束后B2（3天）开始。路径1：A→B1→B2，总工期4+3+3=10天；路径2：A→C，总工期4+5=9天；但原关键路径可能被其他路径替代？需重新绘制网络图：A（4）→B1（3）→B2（3），同时A（4）→C（5）。B2和C的结束时间分别为4+3+3=10和4+5=9，所以最长路径为A→B1→B2（10天），但可能遗漏其他依赖关系，正确关键路径应为A→B1→B2（10天）与原B活动分解后的总工期减少，但实际可能存在其他活动，正确总工期应为4（A）+3（B1）+3（B2）=10天？题目可能存在设计问题，正确选项可能为B（13天），需结合具体逻辑。5.以下关于项目章程的描述，错误的是：A.由项目发起人或高层签发B.明确项目目标和高层级需求C.授权项目经理使用组织资源D.包含详细的风险管理计划答案：D解析：项目章程是启动阶段的输出，包含高层级信息（目标、需求、发起人、项目经理权限），详细计划（如风险管理计划）属于规划阶段输出。二、案例分析题（每题20分，共3题）案例1：某企业启动ERP系统升级项目，项目经理张工在项目初期仅编制了进度计划和成本计划，未进行需求确认便直接进入开发阶段。3个月后，用户提出新增移动终端适配功能，导致开发团队需重新调整架构，进度延误2个月，成本超支15%。问题1：分析项目初期存在的管理问题。问题2：提出改进需求管理的具体措施。答案：问题1：（1）需求管理缺失：未进行需求收集、确认和基线化，导致需求变更缺乏控制；（2）规划过程不完整：未编制范围管理计划、需求管理计划，未定义范围基准（范围说明书、WBS、WBS词典）；（3）相关方管理不足：未充分识别用户（尤其是移动终端使用部门）作为关键相关方，未对齐需求期望；（4）变更管理流程缺失：需求变更未经过CCB（变更控制委员会）审批，导致随意变更影响进度和成本。问题2：（1）完善需求管理流程：①需求收集：通过访谈、问卷、原型法收集用户（包括移动终端部门）的功能需求、非功能需求（如性能、安全性）；②需求分析：组织需求评审会，确认需求的一致性、可行性、优先级，形成需求跟踪矩阵；③需求基线化：将确认的需求纳入配置管理，建立基线，后续变更需走正式变更流程；（2）制定需求管理计划：明确需求变更的触发条件、评估标准（如对进度、成本、质量的影响）、审批权限（CCB组成）；（3）加强相关方参与：定期组织用户代表参与需求评审和阶段验收，确保需求共识；（4）建立变更控制机制：所有变更需提交变更请求，分析影响后由CCB审批，批准后更新范围基准并通知相关方。案例2：某软件开发项目采用敏捷开发，迭代周期为2周。第3次迭代中，开发团队发现前两次迭代完成的功能存在大量缺陷，测试团队无法在迭代结束前完成验证，导致迭代目标未达成。问题1：分析敏捷迭代失败的可能原因。问题2：提出提升迭代质量的具体措施。答案：问题1：（1）迭代规划不充分：未在迭代计划会上明确用户故事的验收标准（DoD，完成定义），导致开发质量不达标；（2）测试介入滞后：测试团队在开发完成后才介入，未实现测试左移（如开发与测试并行、自动化测试提前设计）；（3）持续集成缺失：代码未每日集成并运行自动化测试，导致缺陷累积到迭代后期才暴露；（4）团队协作不足：开发与测试沟通不畅，未及时同步进度和问题，缺乏跨职能协作；（5）DoD标准模糊：未明确“完成”的定义（如单元测试覆盖率、代码评审通过、集成测试通过等），导致开发交付物不完整。问题2：（1）明确DoD标准：在迭代计划会上与团队共同定义用户故事的完成标准（如单元测试覆盖率≥80%、代码评审通过、集成测试通过、用户验收测试用例设计完成），作为迭代交付的硬性条件；（2）测试左移：测试人员在迭代规划阶段参与用户故事拆分，提前编写测试用例；开发过程中每日与测试人员同步进展，及时解决测试中发现的问题；（3）实施持续集成（CI）：使用Jenkins等工具每日集成代码，自动运行单元测试和冒烟测试，及时发现并修复缺陷；（4）加强每日站会的问题暴露：开发人员在站会上同步“遇到的阻碍”（如测试阻塞的问题），团队共同解决（如调配资源、调整任务优先级）；（5）迭代回顾会分析根本原因：针对本次迭代的缺陷问题，使用鱼骨图、5Why法分析原因（如开发人员经验不足、需求理解偏差），制定改进措施（如培训、需求澄清模板）并在下一迭代跟踪。案例3：某政府信息化项目进入收尾阶段，项目经理李工组织了验收会议，用户方签署了验收报告，但后续用户反馈系统存在部分功能不符合需求说明书的情况，要求重新整改。问题1：分析验收阶段存在的管理问题。问题2：提出完善项目收尾流程的措施。答案：问题1：（1）验收标准不明确：未在需求说明书中明确功能的具体验收指标（如字段格式、业务规则），导致验收时仅形式确认，未进行功能验证；（2）验收流程不规范：未按照验收计划执行逐项测试（如功能测试、性能测试、用户验收测试），仅通过会议签署报告，未留存测试记录；（3）文档移交不完整：未向用户提供详细的操作手册、维护文档，导致用户在使用中发现隐含问题；（4）收尾阶段监控缺失：未在验收后进行短期运维支持（如质保期），及时解决用户使用中的问题。问题2：（1）明确验收标准：在需求说明书中定义每个功能的验收标准（如“用户登录功能需支持手机号/邮箱两种方式，验证码60秒内发送”），并在验收计划中列出测试用例；（2）规范验收流程：①预验收：开发团队内部完成系统测试（ST），提交测试报告；②正式验收：用户方按照测试用例执行用户验收测试（UAT），记录测试结果（通过/不通过），不通过项需整改直至全部通过；③签署验收仅当UAT全部通过且文档（需求说明书、测试报告、操作手册）移交完成后，双方签署验收报告；（3）完善文档管理：移交的文档包括技术文档（架构设计、数据库设计）、运维文档（故障处理流程、监控指标）、用户文档（操作手册、常见问题解答）；（4）设置质保期：在合同中约定36个月的质保期，期间提供免费运维支持，及时解决用户使用中的问题，降低后续纠纷风险；（5）经验总结：召开项目总结会，收集团队成员和用户的反馈，形成组织过程资产（如验收checklist、常见问题库），供后续项目参考。三、论文题（50分）请以“信息系统项目的风险管理”为题，结合你的项目实践，论述以下内容：1.项目背景（包括项目目标、规模、周期、涉及的相关方）；2.风险管理过程（规划风险管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、监控风险）的具体实施方法；3.项目中遇到的关键风险及应对措施，以及实施效果。答案（示例）：2023年，我作为项目经理负责某省“智慧政务”平台建设项目，目标是整合26个省直部门的业务系统，实现“一网通办”，覆盖全省800万企业和1.2亿自然人。项目规模约1.2亿元，周期24个月，涉及相关方包括省大数据管理局（甲方）、26个省直部门（业务需求方）、第三方数据提供方（如公安、税务）、开发团队（120人，分需求、开发、测试、运维小组）。在风险管理过程中，我严格按照PMBOK指南的六大过程开展工作：1.规划风险管理：项目启动阶段，组织核心团队（包括甲方代表、技术专家）召开风险管理规划会，制定《风险管理计划》。明确风险分类（技术风险、需求风险、外部风险）、风险概率和影响矩阵（5×5级）、风险管理职责（项目经理统筹，各小组负责人识别本领域风险）、报告频率（每周风险日志更新，每月风险评审会）。2.识别风险：采用头脑风暴法、核对单法、访谈法识别风险。需求小组提出“省直部门业务流程差异大，需求整合困难”；技术小组提出“跨部门数据接口标准不统一，数据互通失败”；外部风险包括“政策变化导致合规要求调整”。最终识别出32个风险，录入风险登记册。3.实施定性风险分析：使用概率和影响矩阵评估风险优先级。例如，“需求整合困难”概率80%（高），影响9分（极高，可能导致范围蔓延），优先级第1；“数据接口标准不统一”概率60%（中），影响7分（高），优先级第3；“政策变化”概率30%（低），影响8分（高），优先级第2。4.实施定量风险分析：对高优先级风险进行量化。通过蒙特卡洛模拟分析“需求整合困难”对进度的影响，结果显示可能导致工期延误46周；使用决策树分析“政策变化”的应对成本（整改需增加200万元，不整改可能面临处罚500万元），确定需主动跟踪政策动态。5.规划风险应对：针对“需求整合困难”，采用“减轻”策略：成立跨部门需求工作组（每周2次例会），制定《需求冲突解决流程》（争议问题由省大数据局裁决）；针对“数据接口标准不统一”，采用“转移”策略：在合同中约定第三方数据提供方需按我方标准改造接口，否则扣除10%服务费用；针对“政策变化”，采用“接受”策略，预留5%管理储备（600万元）应对整改需求。6.监控风险：每周更新风险日志，跟踪风险状态。项目第8个月，省营商环境局发布新政策，要求平台增加“企业信用预警”功能，触发“政策变化”风险。立即启动管理储备，组织需求小组3天内完成功能需求分析，开发小组2周内完成模块开发，测试小组1周内完成验证，最终仅增加成本180万元（低于预期500万元），未影响整体工期。