2025上半年软考考试真题及答案

2025上半年软考考试练习题及答案一、单项选择题（共75题，每题1分，共75分）1.某信息系统项目采用敏捷开发模式，项目经理在迭代规划会议中发现，团队成员对用户故事的分解粒度存在分歧。根据敏捷最佳实践，以下处理方式最合理的是（）。A.要求团队严格按照《敏捷开发指南》中的标准分解用户故事B.组织团队讨论用户故事的“完成标准”（DefinitionofDone），并基于共识调整分解粒度C.由项目经理直接指定分解粒度，确保迭代计划的可执行性D.推迟迭代规划会议，等待产品负责人明确所有用户故事的优先级后再处理答案：B解析：敏捷强调团队自组织和共识驱动，用户故事的分解粒度应服务于“完成标准”的达成。通过团队讨论明确DoD（完成标准），能确保分解的合理性，避免因机械遵循标准或个人决策导致的偏差。2.某项目需采购500台服务器，招标文件中规定“服务器内存需≥32GB”，但供应商A提供的投标文件中写明“服务器内存为32GB”，供应商B写明“内存为32GB（可扩展至64GB）”。根据《政府采购法》及招投标相关法规，评标委员会应认定（）。A.供应商A和B均满足要求，优先选择BB.供应商A满足要求，B因“可扩展”表述不明确视为不响应C.供应商B满足要求，A因未注明扩展性视为不响应D.两者均不满足，需澄清后重新评审答案：A解析：招标文件中的“≥32GB”为最低要求，供应商A明确提供32GB，符合要求；供应商B提供32GB且可扩展，属于优于招标要求的响应，不构成废标条件。3.某项目进度计划如下图所示（单位：天），关键路径的总工期为（）天。```A（3）→B（5）→C（4）A（3）→D（6）→E（2）→C（4）B（5）→F（3）→E（2）→C（4）```A.15B.16C.17D.18答案：C解析：关键路径是项目中最长的路径，决定总工期。各路径计算如下：A→B→C：3+5+4=12A→D→E→C：3+6+2+4=15A→B→F→E→C：3+5+3+2+4=17（最长路径）B→F→E→C：5+3+2+4=14（不包含A的起始，非关键）4.关于信息系统项目风险应对策略，以下描述错误的是（）。A.针对“关键开发人员可能离职”的风险，与候选人提前签订备用协议属于“转移”策略B.针对“新技术兼容性不足”的风险，先进行小范围试点属于“减轻”策略C.针对“政策调整导致项目合规成本增加”的风险，预留应急储备属于“接受”策略D.针对“第三方服务延迟交付”的风险，合同中明确高额违约金属于“转移”策略答案：A解析：备用协议属于“减轻”策略（降低风险发生的影响），而“转移”策略通常通过保险、分包等方式将风险责任转移给第三方。5.某项目进行到第8周，挣值分析数据如下：PV=80万元，EV=75万元，AC=82万元。则该项目的进度绩效指数（SPI）和成本绩效指数（CPI）分别为（）。A.SPI=0.9375，CPI=0.9146B.SPI=1.0667，CPI=1.0933C.SPI=0.9375，CPI=1.0933D.SPI=1.0667，CPI=0.9146答案：A解析：SPI=EV/PV=75/80=0.9375；CPI=EV/AC=75/82≈0.9146。（注：因篇幅限制，此处仅展示前5题，实际考试中单项选择题共75题，覆盖项目启动、规划、执行、监控、收尾全流程，涉及范围管理、时间管理、成本管理、质量管理、资源管理、沟通管理、风险管理、采购管理、相关方管理及IT技术基础等模块。）二、案例分析题（共3题，每题25分，共75分）案例一：进度与成本管理问题某公司承接了一个企业资源计划（ERP）系统开发项目，合同工期6个月，预算120万元。项目执行到第3个月末时，项目经理收集到以下数据：计划完成模块：需求分析（100%）、系统设计（80%）、编码（20%）实际完成情况：需求分析（100%，花费15万元）、系统设计（60%，花费25万元）、编码（10%，花费10万元）各阶段预算：需求分析20万元，系统设计40万元，编码30万元，测试30万元（测试阶段尚未开始）。问题1：计算第3个月末的PV、EV、AC，并判断项目的进度和成本绩效。问题2：若项目后续按当前CPI执行，预测项目完工时的总成本（EAC）。问题3：针对进度滞后和成本超支问题，提出3条具体改进措施。答案及解析：问题1：PV（计划值）：需求分析（20万元×100%）+系统设计（40万元×80%）+编码（30万元×20%）=20+32+6=58万元EV（挣值）：需求分析（20万元×100%）+系统设计（40万元×60%）+编码（30万元×10%）=20+24+3=47万元AC（实际成本）：15+25+10=50万元进度绩效：SPI=EV/PV=47/58≈0.81（<1，进度滞后）成本绩效：CPI=EV/AC=47/50=0.94（<1，成本超支）问题2：若后续按当前CPI执行，EAC=BAC/CPI=120/0.94≈127.66万元（BAC为完工预算120万元）。问题3：改进措施：①进度方面：对系统设计和编码阶段进行赶工（如增加资源、加班），或快速跟进（在需求确认后并行开展部分编码工作）；②成本方面：分析超支原因（如系统设计阶段是否存在冗余工作），优化资源分配，减少非必要支出；③管理方面：加强每日站会沟通，明确各任务责任人及截止时间，使用甘特图跟踪关键路径任务。案例二：沟通与相关方管理问题某政府部门委托开发“智慧政务服务平台”，涉及市场监管、税务、人社等多个委办局作为用户部门。项目启动阶段，项目经理仅与甲方项目负责人（信息中心主任）对接，未主动联系各委办局业务骨干。需求调研时，市场监管局提出需要对接其内部审批系统，但该需求未在前期沟通中提及；税务部门认为平台界面不符合其业务操作习惯，要求重新设计。这些问题导致需求变更频繁，项目进度延迟20%。问题1：分析项目沟通管理存在的主要问题。问题2：列举3个关键相关方，并说明应如何管理。问题3：提出4条改进沟通管理的具体措施。答案及解析：问题1：主要问题：①相关方识别不全面，未覆盖各委办局业务骨干等关键用户；②沟通计划缺失，仅与甲方信息中心主任单向沟通，未建立多渠道沟通机制；③需求确认环节遗漏，未在调研前收集各业务部门的潜在需求。问题2：关键相关方及管理方式：①各委办局业务骨干：属于“高影响高利益”相关方，需主动参与需求调研，定期邀请其评审需求文档；②甲方信息中心主任：属于“高影响中利益”相关方，需定期汇报项目进度，争取其对跨部门协调的支持；③公司高层：属于“中影响高利益”相关方，需通过周报或简报说明项目风险及资源需求。问题3：改进措施：①编制《相关方登记册》，通过访谈识别所有关键相关方（如各委办局业务负责人、技术对接人）；②制定《沟通管理计划》，明确沟通频率（如每周与业务部门开需求确认会）、沟通方式（如线上会议+线下文档）；③在需求调研阶段增加“业务场景模拟”环节，邀请各委办局人员现场演示现有业务流程，挖掘隐性需求；④建立变更控制委员会（CCB），规范需求变更流程，避免随意变更导致的进度延误。案例三：质量管理问题某医疗影像系统开发项目中，测试团队发现多个严重缺陷：影像标注功能在高并发下响应时间超过5秒（需求要求≤2秒）；患者隐私数据加密算法不符合《个人信息保护法》要求；部分检查报告模板与医院现有HIS系统格式不兼容。项目经理认为“测试是后期环节，只要上线前修复即可”，未在开发过程中关注质量。问题1：分析项目质量管理失败的根本原因。问题2：列举3种质量控制工具或技术，说明可如何应用于本项目。问题3：提出4条加强质量管理的具体措施。答案及解析：问题1：根本原因：①质量规划缺失，未在项目启动时定义质量标准（如响应时间、加密算法）；②质量保证（QA）未贯穿全流程，仅依赖后期测试；③需求评审不严格，未验证影像标注功能的性能需求和模板兼容性需求。问题2：质量控制工具及应用：①因果图（鱼骨图）：分析影像标注功能响应慢的原因（如数据库查询效率、前端渲染逻辑、服务器配置）；②核对单：在需求评审时使用核对单检查是否覆盖《个人信息保护法》的加密要求；③性能测试：通过负载测试模拟高并发场景，验证响应时间是否达标。问题3：改进措施：①在规划阶段编制《质量计划》，明确各阶段质量目标（如开发阶段代码覆盖率≥80%，测试阶段缺陷密度≤2个/千行）；②引入QA工程师参与需求评审、设计评审和代码走查，在开发过程中进行质量检查；③对隐私数据加密算法进行第三方安全认证，确保符合法规要求；④与医院HIS系统提供方对接，获取模板格式规范，在开发阶段完成兼容性测试。三、论文题（共1题，75分）题目：论信息系统项目的范围管理要求：结合你参与的信息系统项目，论述范围管理的过程、方法及实践经验。需包括以下内容：1.项目背景（需说明项目目标、规模、涉及的主要相关方）；2.范围管理各过程（规划范围管理、收集需求、定义范围、创建WBS、确认范围、控制范围）的具体实施方法；3.项目实施中遇到的范围管理问题及解决方案；4.总结范围管理对项目成功的关键作用。范文示例：论信息系统项目的范围管理2023年6月至2024年12月，我作为项目经理主持了某三甲医院“智慧医疗影像共享平台”项目。项目目标是实现医院与区域内5家社区卫生服务中心的影像数据互通，支持跨机构调阅、标注和诊断，提升基层诊疗效率。项目总投资800万元，工期18个月，涉及的主要相关方包括医院信息中心、放射科、社区卫生服务中心医生、影像设备供应商及卫健委监管部门。一、范围管理各过程的实施方法1.规划范围管理：项目启动后，我组织核心团队（包括需求分析师、QA工程师）编制《范围管理计划》。通过参考组织过程资产（如过往医疗系统项目的范围模板）和专家访谈（邀请卫健委信息化专家），明确了范围管理的工具（如需求跟踪矩阵）、方法（如用户故事映射）及相关方参与方式（如每周需求评审会）。2.收集需求：针对多相关方特点，采用了多种需求收集方法：对医院放射科医生（核心用户），通过焦点小组访谈梳理日常影像调阅的痛点（如跨机构调阅需人工拷贝，耗时30分钟以上）；对社区医生（终端用户），使用问卷调研收集功能需求（如需要移动端查看影像）；对卫健委（监管方），通过文档分析明确数据安全要求（如影像数据需加密存储，调阅日志保留3年）。最终整理出237条原始需求。3.定义范围：以原始需求为基础，结合项目目标，筛选出“跨机构影像调阅（支持DICOM格式）”“移动端轻量化查看（分辨率≥1024×768）”“数据安全审计”等12项核心需求，形成《项目范围说明书》。通过两轮评审（医院信息中心、社区代表、供应商），剔除了“影像3D重建”（超出预算）和“与外省医院互通”（非当期目标）等非关键需求。4.创建WBS：采用“按功能+按阶段”的混合分解方式。一级分解为需求分析、系统设计、开发（前端/后端/接口）、测试（单元/集成/性能）、部署、验收6个阶段；二级分解中，“开发”阶段按功能拆分为“调阅模块”“标注模块”“安全模块”等子任务，确保每个任务可交付（如“调阅模块开发”对应WBS编码1.3.1）。WBS最终分解到50个工作包，每个工作包的工期不超过2周。5.确认范围：在关键里程碑节点（如需求分析完成、系统设计完成、UAT测试完成），组织相关方进行范围确认。例如，UAT阶段邀请10名社区医生实际操作平台，针对“移动端加载速度慢”“标注工具位置不直观”等问题，要求开发团队限期整改，整改通过后签署《范围确认单》，避免后期争议。6.控制范围：建立变更控制流程：任何变更需提交《变更申请单》，说明变更内容、影响（工期/成本）；CCB（由医院信息中心主任、我方技术总监、社区代表组成）每周三开会评审，仅批准“符合项目目标且收益大于成本”的变更。项目期间共收到17份变更申请，其中9份因“增加社区医生电子签名功能”（提升合规性）被批准，8份因“增加药品信息查询”（超出影像共享目标）被拒绝。二、范围管理问题及解决方案项目实施中曾遇到两大范围管理问题：1.需求蔓延：社区卫生服务中心在测试阶段提出“增加影像打印功能”，声称“临床实际需要”。经分析，该功能未在需求阶段提出，且需额外开发打印机驱动接口，预计增加工期2周、成本15万元。解决方案：组织CCB评审，向社区代表说明“打印功能”非合同约定范围，若需增加需签署补充协议并追加预算。最终社区选择放弃该需求，避免了范围失控。2.WBS分解不细致：初期将“接口开发”仅分解为“与HIS系统对接”，未考虑“与LIS系统（检验系统）的间接数据关联”。导致开发阶段发现需额外开