《信息系统项目管理师》案例分析题及解析模拟题6

《信息系统项目管理师》案例分析题及解析模拟题6

一、总体概况与考试技巧

《信息系统项目管理师》案例分析题共 3 道，总分 75 分，覆盖项目范围管理、成本进度管理、配置管理与测试管理三大核心领域。题目均以实际项目场景为背景，侧重考查对项目管理理论的应用能力，以及发现问题、分析问题和解决问题的实操能力，是软考中综合性较强的题型。

考试技巧

1. 审题技巧：先通读案例说明，圈出关键信息，如项目角色分工、时间节点、出现的问题（如进度延迟、需求变更、版本偏差等），再结合问题定位案例中的对应段落，避免遗漏关键线索。
2. 答题逻辑：按 “问题定位→理论依据→案例结合” 的思路答题，如分析项目问题时，先明确涉及的管理领域（如范围管理），再对应该领域的流程（如需求调研、范围评审），最后结合案例描述指出具体问题。
3. 计算类题目：像成本进度管理中的挣值计算、工期概率计算，需牢记核心公式（如 SV=EV-PV、CV=EV-AC，期望工期 T=(乐观工期 + 4× 最可能工期 + 悲观工期)/6），步骤清晰写出计算过程，避免因直接写结果导致失分。
4. 记忆类题目：对于范围说明书内容、配置项状态等固定知识点，需准确记忆关键词，答题时按 “要点分条” 呈现，确保全面且条理清晰。

二、试题一（25 分）

【说明】

某集成公司与某地区燃气公司签订系统升级合同，将原终端抄表系统升级为远程自动抄表系统，并提供 APP 终端应用服务。公司指定原系统项目经理张工负责该项目，此时张工已升任新产品研发部经理。张工调派原项目团队核心骨干刘工、李工分别负责需求调研与开发工作。刘工和李工凭借以往经验完成需求调研与范围说明书，但因甲方负责人兼顾多个项目、时间紧张，需求评审会未能召开。张工考虑到双方有合作基础，且刘工、李工熟悉原系统，为不影响进度，安排项目组采用敏捷开发模式，直接进入设计和编码阶段。

客户验收测试时，甲方提出 APP 的 UI 设计不符合公司风格、不兼容新燃气表数据接口、数据传输加密算法不符合要求等问题，要求全部解决后方可验收。张工向甲方负责人展示公司新产品研发部的新产品，双方口头约定用新产品部分功能完善未实现需求。最终项目通过增加人员、加班赶工，延期 1 个月完成，上线后用户仍发现若干问题。

【问题 1】（8 分）

结合案例，从项目范围管理的角度指出该项目实施过程中存在的问题。

参考答案

1. 未制定范围管理计划，缺乏对范围调研、评审、控制等环节的规划。
2. 需求调研不规范，仅依赖刘工、李工的以往经验，未与甲方等项目干系人充分合作确认需求。
3. 定义范围存在缺陷，需求文件与范围说明书未经过评审，也未获得相关干系人确认。
4. 确认范围环节缺失，未在项目过程中阶段性与甲方确认范围，导致验收测试时才暴露大量问题。
5. 范围控制不到位，未建立范围变更控制流程，面对甲方提出的新需求，仅通过口头约定处理，未规范管理变更。

【问题 2】（6 分）

请写出范围说明书的内容和作用。

参考答案

1. 范围说明书的内容

• 产品范围描述：明确产品或服务的具体功能、特性与要求。
• 验收标准：规定可交付成果需满足的质量、功能等验收条件。
• 可交付成果：列出项目完成后需交付给甲方的所有成果（如 APP、系统接口、文档等）。
• 项目的除外责任：明确项目不包含的工作内容，避免范围模糊。
• 制约因素：影响项目范围实现的限制条件（如时间、资源、技术等）。
• 假设条件：项目实施过程中基于的前提假设（如甲方提供新燃气表接口参数的时间）。

2. 范围说明书的作用

• 确定范围：明确项目的工作边界，避免范围蔓延或遗漏。
• 沟通基础：为项目团队、甲方等干系人提供统一的范围认知，减少沟通偏差。
• 规划和控制依据：指导后续项目计划制定（如进度、成本计划），并作为范围控制的基准。
• 变更基础：当提出范围变更时，以范围说明书为依据评估变更的必要性与影响。
• 规划基础：为项目的其他管理领域（如质量、风险）规划提供前提。

【问题 3】（6 分）

结合案例，阐述张工在需求变更过程中需要完成的具体工作内容。

参考答案

1. 响应变更提出者（甲方）的需求，详细记录变更内容与诉求。
2. 评估变更对项目进度、成本、质量、风险等方面的影响（如甲方提出的 UI 修改对工期的影响）。
3. 参与制定变更应对方案，如评估用新产品功能满足需求的可行性与资源需求。
4. 将变更的技术要求转化为具体的资源需求（如需要增加的开发人员、时间）。
5. 组织变更控制委员会（CCB）对变更进行决策，判断是否批准变更。
6. 根据 CCB 评审结果，组织项目团队实施变更，明确变更执行的责任人与时间节点。
7. 跟踪变更的实施情况，确保变更按计划推进，避免偏离目标。
8. 变更完成后，评估变更效果，确认是否满足甲方需求。
9. 判断变更后的项目是否回归正轨，若存在偏差，及时调整项目计划。

【问题 4】（5 分）

请将下面①~⑤处的答案填写在答题纸的对应栏内。

（1）在每个项目任务的分解单元中都存在可交付成果和 ① ，标志着某个可交付成果或阶段的正式完成。

（2）创建 ② 是将项目的可交付成果和项目工作分解为较小的、更易管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。其最底层的可交付成果或项目工作组成部分称为③。

（3）项目干系人提出变更申请后，一般由④或⑤进行初审。

参考答案

（1）① 里程碑

（2）② WBS（工作分解结构）；③ 工作包

（3）④ 项目经理（PM）；⑤ 配置管理员（CMO）

三、试题二（25 分）

【说明】

某软件开发项目包含 A、B、C、D 四个活动，项目总预算为 52000 元。截至 6 月 30 日，各活动相关信息如下表所示。

活动	成本预算（元）	计划成本（元）	实际进度	实际成本（元）
A	25000	25000	100%	25500
B	12000	9000	50%	5400
C	10000	5800	50%	1100
D	5000	0	0	0

C 活动是项目关键任务，目前刚刚开始，项目经理希望该任务能在 24 天内完成。项目组决定采用快速跟进的方法加快进度，并估算 C 活动的预计工期为乐观 14 天、最可能 20 天、悲观 32 天。

【问题 1】（13 分）

结合案例，计算截至 6 月 30 日各活动的挣值（EV）和项目的进度偏差（SV）、成本偏差（CV），并判断项目的执行绩效。

参考答案

1. 各活动挣值（EV）计算

• 活动 A：EV = 成本预算 × 实际进度 = 25000 × 100% = 25000 元
• 活动 B：EV = 12000 × 50% = 6000 元
• 活动 C：EV = 10000 × 50% = 5000 元
• 活动 D：EV = 5000 × 0% = 0 元

1. 项目整体参数计算

• 计划值（PV）= 各活动计划成本之和 = 25000 + 9000 + 5800 + 0 = 39800 元
• 实际成本（AC）= 各活动实际成本之和 = 25500 + 5400 + 1100 + 0 = 32000 元
• 总挣值（EV）= 各活动 EV 之和 = 25000 + 6000 + 5000 + 0 = 36000 元

1. 偏差计算

• 进度偏差（SV）= EV - PV = 36000 - 39800 = -3800 元
• 成本偏差（CV）= EV - AC = 36000 - 32000 = 4000 元

1. 项目执行绩效

SV <0，说明项目进度延迟；CV> 0，说明项目成本节约。综上，项目当前进度滞后，但成本控制良好。

【问题 2】（3 分）

项目组决定采用快速跟进的方式加快进度，请简述该方式的不足。

参考答案

1. 增加项目风险：快速跟进通常将原本串行的活动改为并行（如 C 活动与其他活动并行推进），可能因活动间依赖关系未理清导致风险增加（如接口冲突）。
2. 可能造成返工：并行活动的成果可能存在兼容性问题，后续需返工调整，反而延误工期。
3. 可能增加项目成本：并行推进可能需要额外的资源（如增加开发人员），或因返工产生额外成本。

【问题 3】（4 分）

如果当前项目偏差属于典型偏差，请计算完工估算成本（EAC）。

参考答案

1. 计算成本绩效指数（CPI）

CPI = EV / AC = 36000 / 32000 = 1.125

1. 计算完工估算成本（EAC）

已知项目总预算（BAC）= 52000 元，典型偏差下 EAC 公式为：

EAC = AC + (BAC - EV) / CPI

代入数据：

EAC = 32000 + (52000 - 36000) / 1.125 = 32000 + 16000 / 1.125 ≈ 46222.22 元

【问题 4】（5 分）

项目经理尝试采用资源优化技术在 24 天内完成 C 活动的目标，请计算能达到项目经理预期目标的概率。

参考答案

1. 计算 C 活动的期望工期（T）

使用三点估算公式：T = (乐观工期 + 4× 最可能工期 + 悲观工期) / 6

代入数据：T = (14 + 4×20 + 32) / 6 = (14 + 80 + 32) / 6 = 126 / 6 = 21 天

1. 计算标准差（δ）

标准差公式：δ = (悲观工期 - 乐观工期) / 6

代入数据：δ = (32 - 14) / 6 = 18 / 6 = 3 天

1. 计算 24 天内完成的概率

• 24 天 = 期望工期（21 天） + 1 个标准差（3 天）
• 在正态分布中，正负 1 个标准差范围内的概率为 68%，即期望工期 ±1δ 的概率为 68%。
• 24 天内完成的概率 = 50%（期望工期内完成概率） + 68% / 2（期望工期到 + 1δ 之间的概率） = 50% + 34% = 84%

四、试题三（25 分）

【说明】

A 公司是一家提供 SaaS 平台服务的公司，小张担任研发流程优化经理。他抽查核心产品的配置管理和测试过程，情况如下：项目组共 10 人，产品经理小马兼任项目经理和配置管理员，另有 7 名开发工程师和 2 名测试工程师。项目采用敏捷开发方法，2 周为一个迭代周期，目前刚完成 3.01 版本的上线。

小张要求查看配置管理库时，小马回复 “正忙着，让测试工程师王工给你看，我们 10 个人都有管理员权限”。小张发现配置库仅分为开发库和产品库：产品库包含上线的 3 个大版本的完整代码和文档资料，但与实际运行版本存在偏差；小版本（如 3.01）仅能在开发库中找到代码，无相关文档。此外，因新需求迭代快，部分细微修改由开发人员直接操作，导致文档与代码不一致。

小张计划对产品 3.01 版本进行一次系统测试，以解决研发流程和系统本身的问题。

【问题 1】（5 分）

结合本案例，从配置管理的角度指出项目实施过程存在的问题。

参考答案

1. 配置库权限管理混乱，项目组 10 人均拥有管理员权限，缺乏权限控制，易导致配置项被误修改。
2. 配置库结构不完整，仅设置开发库和产品库，未建立受控库，无法对处于评审、测试阶段的配置项进行规范管理。
3. 版本管理失控，产品库中上线版本的代码、文档与实际运行版本存在偏差，小版本（3.01）无配套文档。
4. 文档管理缺失，开发人员直接修改代码但未同步更新文档，导致代码与文档不一致。
5. 变更管理不规范，开发人员随意修改配置项，未记录变更原因、内容与责任人，缺乏变更控制流程。
6. 配置审计未落实，未定期对配置项的功能（是否符合需求）和物理（版本、文档一致性）进行审计，导致偏差未及时发现。

【问题 2】（10 分）

结合本案例，帮助测试工程师从测试目的、测试对象、测试内容、测试过程、测试用例设计依据、测试技术 6 个方面，设计核心产品 3.01 版本的系统测试方案。

参考答案

1. 测试目的：发现 3.01 版本系统中的功能缺陷、性能问题及文档偏差，衡量系统质量是否符合 SaaS 平台服务要求，评估系统是否满足用户需求与设计标准。
2. 测试对象：3.01 版本的程序代码（如 SaaS 平台核心功能模块、接口）、相关文档（如用户手册、接口说明文档，若缺失需先补充）。
3. 测试内容

• 功能测试：验证系统核心功能（如 SaaS 平台的用户管理、数据存储、服务调用）是否正常，是否符合需求规格。
• 界面测试：检查系统界面的易用性、一致性，是否符合用户操作习惯。
• 文档测试：核对文档与代码的一致性，检查文档的完整性、准确性（如接口参数描述是否与代码一致）。
• 性能测试：测试系统在正常负载、高负载下的响应时间、并发能力，确保满足 SaaS 平台的服务稳定性要求。
• 兼容性测试：验证系统与常用浏览器、操作系统的兼容性（针对 SaaS 平台特性）。

1. 测试过程

• 测试计划：明确测试范围、资源（测试工程师、环境）、时间节点与交付物（测试报告）。
• 测试设计：根据需求与设计文档，设计测试用例，搭建测试环境（如模拟 SaaS 平台的用户场景）。
• 测试执行：按照测试用例执行测试，记录测试结果，标记缺陷并跟踪修复情况。
• 测试总结：整理测试数据，生成测试报告，分析缺陷原因，提出改进建议。

1. 测试用例设计依据：每个测试用例需包含名称、唯一标识、测试追踪（关联的需求点）、用例说明、初始化要求（如测试环境配置）、输入数据、期望结果、评价准则（如何判断测试通过）、操作步骤、前提约束（如需先完成用户登录）、测试终止条件（如出现严重缺陷时停止测试）。
2. 测试技术：采用黑盒测试（验证功能是否符合需求，不关注内部逻辑）、白盒测试（检查代码内部逻辑、分支覆盖情况）、灰盒测试（结合功能验证与部分内部逻辑检查，如接口测试）。

【问题 3】（6 分）

如果系统测试中需要采用黑盒测试、白盒测试和灰盒测试，请阐述三种测试的含义和用途。

参考答案

1. 黑盒测试

• 含义：又称功能测试，仅关注程序的外部功能，不考虑内部逻辑结构与代码实现。测试时将程序视为 “黑盒”，通过输入预设数据，验证输出结果是否符合需求规格说明书的要求。
• 用途：主要用于验证系统功能是否完整、正确，是否满足用户需求，适用于界面测试、功能测试、兼容性测试等场景（如测试 3.01 版本中用户登录功能是否正常）。

1. 白盒测试

• 含义：又称结构测试或逻辑驱动测试，需了解程序的内部结构、代码逻辑与执行路径。测试时将程序视为 “透明的白盒”，检查内部逻辑是否正确、代码分支是否全覆盖、变量定义与使用是否规范。
• 用途：用于发现代码层面的缺陷（如逻辑错误、死循环），确保代码质量，适用于单元测试、源代码测试等场景（如检查 3.01 版本中数据处理模块的代码分支覆盖情况）。

1. 灰盒测试

• 含义：介于黑盒测试与白盒测试之间，既关注程序的外部功能输出是否正确，也关注部分内部运行状态（如接口参数传递、数据流向），但无需完全了解所有代码逻辑。
• 用途：适用于接口测试、集成测试等场景，可同时验证功能正确性与内部数据处理的合理性（如测试 3.01 版本中 SaaS 平台与外部系统的接口调用是否正常，同时检查接口参数的传递是否符合设计）。

【问题 4】（4 分）

从候选答案中选择正确选项，将该选项编号填入答题纸对应栏内。

配置项的状态通常可分为三种，配置项初建时其状态为 (1)。配置项通过评审后，其状态变为 (2)。此后若更改配置项，则其状态变为 (3)。当配置项修改完毕并重新通过评审时，其状态又变为 (4)。

候选答案：A. 送审稿 B. 草稿 C. 报批稿 D. 征求意见 E. 修改 F. 正式

参考答案

(1) B（草稿）；(2) F（正式）；(3) E（修改）；(4) F（正式）