2026下半年系统集成项目管理工程师第四批次《应用技术》真题及答案

2026下半年系统集成项目管理工程师第四批次《应用技术》真题及答案【试题一】（25分）阅读下列说明，回答问题1至问题4，将解答填入答题纸的对应栏内。【说明】某大型企业A计划构建一套新一代“企业级智能制造数据中台系统”，以整合内部各子系统的生产数据、供应链数据及销售数据，实现数据驱动的决策支持。该项目工期紧，任务重，涉及技术栈复杂，包括大数据处理、人工智能算法及高并发微服务架构。企业A指派具有丰富技术经验的李工担任项目经理，并组建了包括架构师、数据工程师、开发人员及测试人员在内的20人项目团队。项目启动后，李工立即组织召开了项目启动会议，明确了项目目标。随后，李工凭借个人经验，制定了详细的项目进度计划，并直接分配给团队成员开始执行。在项目实施过程中，为了赶进度，李工省略了需求调研阶段的部分细节，直接参考旧系统的需求规格说明书进行设计。项目执行至第3个月末，李工发现项目实际进度落后于计划约15%，且成本超支约10%。此时，客户方提出增加数据可视化大屏展示功能，李工认为该功能有助于提升项目验收通过率，未进行变更评估便直接答应客户，并安排开发人员着手开发。第5个月，项目进入集成测试阶段，测试团队发现由于各子系统数据接口标准不统一，导致数据清洗失败率高达40%，大量数据无法入库。同时，由于前期需求细节缺失，开发出的部分报表功能不符合业务部门实际使用习惯，导致需要大规模返工。李工试图通过加班赶工来弥补进度，但团队成员因长期加班产生抵触情绪，两名核心开发人员提出离职申请。【问题1】（10分）请结合案例，指出李工在项目管理过程中存在的问题。【问题2】（6分）请列举项目进度控制的主要步骤。【问题3】（4分）请简述变更管理流程中“变更初审”的目的和主要内容。【问题4】（5分）结合本案例，作为项目经理，应采取哪些措施应对团队成员的离职风险？【试题二】（25分）阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。【说明】某市政务服务中心为了提升“互联网+政务服务”水平，决定开发“全市统一政务云服务平台”。项目采用公开招标方式，最终选定具有相关资质的B公司负责承建。项目合同金额为1200万元，工期为12个月，采用固定总价合同。项目范围包括：基础设施云化改造、政务数据共享交换平台建设、统一身份认证系统开发及门户网站迁移。项目实施过程中，发生如下事件：事件1：在需求分析阶段，政务服务中心提出需要增加与省里“跨省通办”系统的对接接口，并要求在原有安全防护体系基础上，增加符合国密标准的加密模块。B公司项目经理认为这些不在原合同范围内，拒绝了客户的变更请求，导致双方关系紧张。事件2：项目进行到第6个月，B公司发现政务服务中心原有的基础硬件设施老化严重，无法满足云平台的高性能要求，建议客户更换硬件。政务服务中心认为B公司应在投标前进行充分调研，坚持要求B公司在现有硬件上完成部署，否则视为违约。事件3：项目接近尾声时，政务服务中心指出门户网站的页面风格不符合最新的政府网站集约化建设规范，要求B公司进行UI重构。B公司表示合同中已明确页面风格参考旧版网站，且目前项目已无预算支持UI重构工作。【问题1】（10分）请根据《中华人民共和国政府采购法》及相关项目管理知识，分析该项目在采购管理和合同管理方面存在哪些问题？【问题2】（8分）针对事件1中客户提出的变更请求，项目经理应如何正确处理？请简述处理流程。【问题3】（7分）请判断以下合同类型（固定总价合同、固定单价合同、成本补偿合同）分别适用于什么情况？并分析本案例采用固定总价合同是否恰当，说明理由。【试题三】（25分）阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。【说明】某软件开发公司承接了一家银行的“核心信贷系统升级”项目。该项目涉及银行核心账务数据的处理，对系统的安全性、可靠性及数据一致性要求极高。项目组决定采用V模型进行开发管理，并制定了详细的质量管理计划。在测试阶段，项目组重点关注了以下方面：1.单元测试：由开发人员在编码完成后自行进行，主要检查模块内部逻辑错误。2.集成测试：将所有模块组装后进行测试，重点检查模块间的接口参数传递是否正确。3.系统测试：在模拟环境中，模拟银行实际业务场景，验证系统是否满足需求规格说明书定义的所有功能和非功能需求。4.验收测试：邀请银行信贷部门业务人员参与，在实际运行环境中进行操作验证。项目上线运行一个月后，系统在高并发交易场景下出现了几次死锁现象，导致部分交易失败，虽然数据未丢失，但严重影响了银行业务办理，银行客户对此表示强烈不满。【问题1】（8分）请简述V模型的主要优点和缺点。【问题2】（10分）结合案例，请分析项目组在测试过程中可能遗漏了哪些关键测试类型或环节？针对“核心信贷系统”的特点，还应重点进行哪些测试？【问题3】（7分）请简述质量保证（QA）与质量控制（QC）的区别与联系。【试题四】（25分）阅读下列说明，回答问题1至问题4，将解答填入答题纸的对应栏内。【说明】某公司启动了一项“企业数字化转型战略规划”项目，旨在通过引入云计算、大数据和人工智能技术，重构业务流程。该项目由公司高层直接发起，张工被任命为项目集经理，负责统筹管理该战略下的多个关联项目，包括“CRM系统重构”、“ERP云迁移”、“数据湖建设”及“智能客服机器人”等项目。在项目集初期，张工主要关注各子项目的进度和技术实现，认为只要各子项目按时交付，项目集即算成功。然而，在“CRM系统重构”项目上线后，发现其产生的客户数据无法直接被“智能客服机器人”项目调用，因为两个项目采用了不同的数据定义标准。同时，“ERP云迁移”项目由于预留接口不足，无法与“数据湖建设”项目进行实时数据同步。为了解决这些问题，张工召开了项目群协调会议，决定成立跨项目的技术架构小组，统一数据标准和接口规范。但这导致部分已开发完成的模块需要推倒重来，造成了较大的资源浪费和进度延误。此外，由于各子项目资源争夺激烈，尤其是资深架构师和时间窗口的冲突，导致整体协同效率低下。【问题1】（8分）请结合案例，分析张工在项目集管理中存在的主要问题。【问题2】（6分）项目集管理包括项目集治理、干系人管理、范围管理等多个组件。请简述项目集管理与单项目管理的主要区别。【问题3】（6分）为了解决资源冲突问题，张工应制定合理的资源管理计划。请列举资源管理计划的主要内容。【问题4】（5分）在项目集管理中，组件治理通常涉及依赖关系管理。请说明依赖关系管理的目的，并列举常见的依赖关系类型。【试题五】（25分）阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。【说明】某互联网公司计划开发一款“基于AI的个性化学习推荐引擎”。该项目技术新颖，市场需求尚不完全明确，且需求预计在开发过程中会频繁变更。为了应对不确定性，项目组决定采用敏捷开发方法，并使用Scrum模型进行管理。项目组组建了由产品负责人、ScrumMaster和开发团队组成的敏捷团队。在第一次Sprint规划会议上，产品负责人拿出了一份包含100个功能点的详细需求文档，要求团队在第一个Sprint（为期2周）内完成前20个高优先级功能点的开发。开发团队评估后认为工作量过大，无法完成，但产品负责人坚持认为这些功能对MVP（最小可行性产品）至关重要，必须完成。Sprint进行到第5天，产品负责人又临时插入了3个紧急Bug修复任务和2个新功能需求，要求团队在本Sprint内一并处理。ScrumMaster为了维护客户关系，直接同意了产品负责人的要求，并通知团队调整任务优先级。Sprint团队成员感到困惑和不满，工作节奏被打乱。Sprint评审会议时，团队只完成了原定任务的60%，且未完成的部分质量较差，无法演示。产品负责人对此非常不满。回顾会议上，团队成员互相指责，气氛尴尬，未能总结出有效的改进措施。【问题1】（10分）请结合Scrum的相关原则和实践，指出该敏捷团队在执行过程中存在的问题。【问题2】（8分）请简述Scrum框架中三个角色的主要职责。【问题3】（7分）在敏捷开发中，用户故事是一个核心概念。请简述一个好的用户故事应遵循的INVEST原则。【试题一】参考答案及解析【问题1】李工在项目管理过程中存在的主要问题如下：1.计划制定不科学：李工“凭借个人经验”制定进度计划，未让项目团队参与计划制定，导致计划不合理且团队承诺度低。2.缺少重要的计划过程：案例中只提到了进度计划，未提及质量管理计划、风险管理计划、沟通管理计划等，导致后续出现质量、风险和沟通问题。3.忽视需求管理：李工“省略了需求调研阶段的部分细节，直接参考旧系统”，这是导致后续报表功能不符合业务习惯、大规模返工的根本原因。4.变更管理失控：李工未进行变更评估（如影响分析、成本效益分析）便直接答应客户新增功能，且未走正式的变更控制流程，导致范围蔓延和进度成本失控。5.进度监控不力：直到第3个月末才发现进度落后和成本超支，说明缺乏有效的进度监控机制（如未定期进行绩效报告、偏差分析）。6.质量管理缺失：集成测试发现数据接口标准不统一，说明缺乏统一的质量保证活动和架构设计评审，未在早期发现接口问题。7.人力资源管理不当：面对进度落后，单纯依靠“加班赶工”而未分析根本原因，导致团队疲劳、核心成员离职，缺乏有效的团队建设和激励措施。8.干系人管理不足：未能有效管理客户期望，随意答应变更导致后期交付压力；也未能及时识别和管理团队成员的消极情绪。【问题2】项目进度控制的主要步骤包括：1.收集数据：收集项目实际进展数据，如任务完成情况、开始和结束时间、实际消耗资源等。2.分析进度：将实际进度与计划进度进行比较，计算偏差（如SV、SPI），分析偏差产生的原因。3.制定措施：针对进度偏差，制定并选择相应的纠正措施或预防措施（如赶工、快速跟进、调整范围等）。4.更新计划：根据批准的变更措施，更新项目进度基准及相关管理计划。5.报告绩效：向相关干系人报告项目进度状态和绩效信息。【问题3】变更初审的目的：1.对变更请求进行初步筛选，确保提交的变更请求是合理的、有价值的。2.验证变更请求的完整性，判断是否属于项目范围，是否需要进一步处理。3.评估变更的必要性，过滤掉不必要或不可行的变更，减轻CCB（变更控制委员会）的负担。变更初审的主要内容：1.格式审核：检查变更申请单的填写是否规范、完整。2.权限审核：检查提出变更的干系人是否有权提出变更。3.技术初步评估：初步判断变更在技术上是否可行。4.影响初步分析：初步评估变更对项目范围、进度、成本、质量等方面的影响。5.资源初步评估：判断组织是否有资源支持该变更。【问题4】作为项目经理，应对团队成员离职风险的措施包括：1.建立知识共享机制：实施结对编程、代码审查、技术文档共享，确保项目知识不依赖于单个人员。2.进行资源备份：识别核心岗位，培养后备人员或设置AB角机制。3.加强团队建设与激励：关注团队成员的工作满意度，实施激励措施（如奖金、表彰、职业发展机会），营造良好的团队氛围。4.做好人员储备规划：在人力资源管理计划中预留招聘渠道，确保关键人员离职后能及时补充。5.及时沟通与交接：一旦发现离职苗头，及时沟通了解原因，并立即启动工作交接流程，最小化对项目的影响。【试题二】参考答案及解析【问题1】该项目在采购管理和合同管理方面存在的主要问题：1.合同类型选择风险：对于需求明确、技术复杂但可能存在变更的项目，采用固定总价合同虽然能转移成本风险，但在本案例中，由于前期需求调研不充分（未发现硬件老化问题），导致合同执行困难。2.采购文件准备不充分：B公司（乙方）在投标前未对甲方现有基础设施进行充分的现场勘察和技术尽职调查，导致对硬件环境评估失误。3.合同条款不清晰或缺失：合同中关于“页面风格”的约定与最新的政策规范冲突，且未明确硬件环境责任归属，导致后期扯皮。4.工作说明书（SOW）定义不严谨：未在合同或SOW中明确“跨省通办”接口和国密加密模块是否包含在范围内，导致对范围理解不一致。5.变更管理流程缺失：项目经理直接拒绝客户变更，未按合同约定的变更流程处理，导致双方关系紧张。6.索赔管理不当：对于甲方硬件环境不支持导致的问题，项目经理未及时发出索赔意向书或保留相关证据。7.缺乏风险共担机制：在政府采购项目中，对于不可预见的基础设施风险，双方未在合同中约定合理的风险分担方式。【问题2】针对客户提出的变更请求，项目经理应按以下流程正确处理：1.接收与记录：正式接收客户的变更请求，并详细记录在《变更申请单》中。2.初步分析：对变更请求进行初审，分析其合理性、完整性及对项目的影响（技术、成本、进度、质量、风险等）。3.提交CCB审批：将变更申请及初步分析结果提交给变更控制委员会（CCB）或具有相应权力的决策机构审批。4.通知干系人：将CCB的审批结果（批准或驳回）书面通知给提出变更的客户及相关项目干系人。5.实施变更：若变更被批准，则更新项目基准（范围、进度、成本），并组织团队实施变更。6.监控与验证：对变更的实施过程进行监控，变更完成后，验证变更结果，并归档相关文档。【问题3】合同类型适用情况分析：1.固定总价合同：适用于工作范围明确、需求清晰、技术成熟、工期短、风险较小的项目。2.固定单价合同：适用于工作范围难以界定、工作量无法准确预估，但单价可以确定的项目（如按人天计费的服务类项目）。3.成本补偿合同：适用于范围无法界定、风险极大、或需要乙方投入大量研发资源且甲方愿意承担所有成本风险的项目（通常用于科研项目）。本案例采用固定总价合同是否恰当：不完全恰当（或存在较大风险）。理由：虽然该项目是政府采购项目，通常倾向于固定总价以控制预算。但本项目涉及“基础设施云化改造”和“硬件环境依赖”，如果在签订合同前未对现有硬件环境进行彻底的技术确认，硬件老化风险属于乙方不可控的外部风险，强行使用固定总价合同会导致乙方在遇到硬件不兼容时陷入被动，引发合同纠纷。更适合在明确硬件责任的前提下，对软件部分采用固定总价，对涉及硬件基础的部分采用单价或成本补偿方式，或者在合同中约定因硬件环境导致的变更可调整合同价款。【试题三】参考答案及解析【问题1】V模型的主要优点：1.强调测试：将测试过程与开发过程对应起来，明确了测试阶段的目标和依据。2.阶段清晰：包含验证和确认活动，每个阶段都有明确的输入输出，便于管理。3.早期介入：使得测试设计和测试计划可以在需求分析和设计阶段就开始，有利于尽早发现缺陷。V模型的主要缺点：1.灵活性差：是线性模型，要求在项目早期明确需求，不适应需求频繁变更的项目。2.测试滞后：虽然测试设计提前，但实际执行测试集中在开发后期，导致缺陷发现得晚，修复成本高。3.用户介入晚：用户直到系统测试或验收测试阶段才能看到产品，反馈不及时。4.风险控制不足：在项目初期无法很好地识别和规避技术风险。【问题2】项目组可能遗漏的测试类型或环节：1.性能测试：系统上线后在高并发下出现死锁，说明未进行充分的负载测试、压力测试和并发测试。2.安全性测试：核心信贷系统对安全性要求高，案例未提及渗透测试、漏洞扫描等安全测试。3.数据一致性测试：虽然提到了功能测试，但死锁可能导致数据异常，需专门针对事务ACID特性进行测试。4.配置项测试/环境测试：未充分验证生产环境与测试环境配置差异对性能的影响。5.回归测试：在缺陷修复后，未进行充分的回归测试以确保修复未引入新问题。针对“核心信贷系统”特点，还应重点进行：1.可靠性测试：包括高可用性测试、容错测试、恢复测试（如灾难恢复）。2.数据完整性测试：确保在各种异常情况下（如断电、网络中断）数据不丢失、不错乱。3.并发与锁机制测试：专门测试数据库锁、资源锁在高并发下的表现，避免死锁。4.接口测试：核心系统通常与外围系统有大量交互，需严格接口测试。【问题3】质量保证（QA）与质量控制（QC）的区别与联系：区别：1.关注点不同：QA关注过程，确保过程遵循既定的标准和规范；QC关注产品，确保产品满足需求。2.目的不同：QA是“预防”缺陷，提供信心；QC是“发现”缺陷，检查结果。3.时间点不同：QA贯穿项目全生命周期；QC通常在产品产生后进行（如测试阶段）。4.执行者不同：QA通常由QA部门或独立人员执行；QC通常由测试人员或开发人员执行。联系：1.目标一致：都是为了提供满足质量要求的产品或服务。2.相辅相成：QA为QC提供过程保障，减少QC发现的缺陷；QC的结果反馈给QA，用于改进过程。3.缺一不可：仅有QC可能导致缺陷重复产生，仅有QA无法验证最终产品质量。【试题四】参考答案及解析【问题1】张工在项目集管理中存在的主要问题：1.缺乏项目集整体规划：张工只关注子项目进度，未在项目集层面统一规划架构、标准和资源，导致各子项目各自为政。2.忽视依赖关系管理：未识别和管理子项目间的依赖关系（如数据流、接口依赖），导致CRM与数据湖无法对接。3.缺乏统一的技术治理：未建立统一的数据标准和接口规范，导致后期返工和资源浪费。4.干系人管理不足：未有效协调各子项目干系人的期望，导致资源冲突和协同效率低。5.组件管理不当：在组件（子项目）选择和优先级排序上缺乏全局视角，导致已开发模块因标准不统一而废弃。6.资源管理失败：未在项目集层面进行资源的统一调配和平衡，导致关键资源（架构师）冲突。【问题2】项目集管理与单项目管理的主要区别：1.管理范围不同：项目集管理通过协调多个相关项目来实现战略收益；单项目管理侧重于交付特定的产品或服务。2.关注点不同：项目集管理关注“收益”和“依赖关系”；单项目管理关注“任务完成”和“约束条件（进度、成本）”。3.适应性变更：项目集管理需要根据环境和战略变化主动调整项目集组件；单项目通常尽量控制变更。4.管理复杂度：项目集管理涉及多项目间的资源共享、依赖治理和冲突解决，复杂度更高。5.规划周期：项目集规划周期通常更长，且具有滚动规划的特性。【问题3】资源管理计划的主要内容：1.识别资源：识别项目集所需的各种资源类型（人力、设备、材料、资金）及其数量和技能要求。2.资源获取方式：明确资源是内部调配还是外部采购。3.资源分配原则：定义资源分配的优先级规则和策略（如优先保障关键路径项目）。4.资源进度安排：制定资源的使用时间表和释放计划。5.资源优化策略：制定资源平衡、资源平滑等解决冲突的方法。6.资源绩效管理：定义资源使用效率的考核指标。7.角色与职责：明确资源经理和项目经理在资源管理中的职责。【问题4】依赖关系管理的目的：确保项目集内各组件之间的依赖关系被识别、分析和管理，以优化整体进度，消除冲突，确保项目集目标的实现。常见的依赖关系类型：1.内部依赖：项目集内部组件之间的依赖关系（如项目A的输出是项目B的输入）。2.外部依赖：项目集组件与外部实体（如外部项目、组织运营环境）之间的依赖关系。3.强制依赖：法律或合同要求的依赖关系，也称为硬逻辑。4.选择性依赖：基于最佳实践或特定偏好关系的依赖，也称为软逻辑。5.共享依赖：多个组件共同依赖同一资源或同一输出。【试题五】参考答案及解析【问题1】该敏捷团队在执行过程中存在的问题：1.Sprint规划会议违规：产品负责人（PO）试图单方面决定Sprint的内容，违背了“开发团队自主决定Sprint能完成多少工作”的原则。2.Sprint目标未达成共识：PO与团队在任务量上未达成一致，强行启动Sprint，导致团队士气低落。3.Sprint期间随意变更：PO在Sprint进行中插入新任务，ScrumMaster未阻止，严重违反了“Sprint期间不允许变更需求”的Scrum原则。4.ScrumMaster角色失职：ScrumMaster未保护团队免受外部干扰，反而同意了不合理的变更请求。5.缺乏透明度和沟通：Sprint评审时无法演示，说明团队在每日站会中未及时暴露风险和问题。6.回顾会议流于形式：回顾会议变成了互相指责，未能遵循“不论对错，只论改