试题一（20 分）
某系统集成项目共有 8 个活动，项目完工预算BAC为100万元，项目开展10天后，各活动的信息统计如下:
|
活动名称 |
前置活动 |
工时（天） |
完成百分比（%） |
PV（万元） |
AC（万元） |
|
A |
- |
2 |
100 |
5 |
5 |
|
B |
- |
3 |
100 |
20 |
18 |
|
C |
B |
2 |
100 |
10 |
11 |
|
D |
C、A |
5 |
80 |
15 |
13 |
|
E |
C |
4 |
60 |
10 |
5 |
|
F |
D |
6 |
0 |
10 |
0 |
|
G |
E |
3 |
0 |
15 |
0 |
|
H |
F、G |
1 |
0 |
15 |
0 |
【问题 1】(6 分)
请确定本项目的关键路径并计算项目总工期。
【问题 2】(8 分)
假设项目成本按照进度平均分配，紧前活动完成后紧后活动立即开始，请计算项目当前的挣值(EV)，以及进度绩
效指数(SPI)与成本绩效指数(CPI)并进行绩效分析。(结果保留两位小数）
【问题 3】(6 分)
如果当前偏差是典型的,请计算项目的 ETC 和 EAC。(结果保留两位小数)
答案：
【问题 1】
关键路径是 BCDFH，工期是17
【问题 2】
按计划，第 10 天结束时，应该完成 A、B、C、D、E、1/3G。
PV=5+20+10+15+10+15/3=65
EV=A*100%+B*100%+C*100%+D*80%+E*60%=5+20+10+12+6=53
AC=5+18+11+13+5=522
SPI=EV/PV=53/65=0.82
CPI=EV/AC=53/52=1.02
目前进度滞后，成本节约。
【问题 3】
典型,按照现在绩效进行预测。
ETC=(BAC-EV)/CPI=(100-53)/1.02=46.11 万元
EAC=AC+ETC=52+46.11=98.11 万元
试题二18 分
某系统集成公司承接“某市智慧校园教务管理系统开发项目”，项目需完成学生信息管理、课程调度、成绩统计3大核心模块的研发，需符合国家标准《信息技术软件产品质量要求与评价》中“软件功能性、可靠性、易用性”三级要求。任命质量保证工程师赵某负责过程合规审查，测试工程师孙某负责缺陷跟踪，项目经理刘某负责质量决策与资源协调。赵某编制了项目质量管理计划，明确需求覆盖率>95%、软件缺陷率≤0.4个/千行代码、测试用例通过率>92%三项目标。项目设定需求基线评审、详细设计评审、单元测试验收、系统测试验收4项审查活动。应用需求跟踪矩阵关联需求与测试用例，应用缺陷跟踪工具MANTIS记录缺陷处理流程，应用鱼骨图分析质量问题根本原因，以支撑项目管理活动。项目团队依据质量管理计划执行情况如下:
质量成本投入:团队《信息技术软件产品质量要求与评价》标准培训2.2万元、质量检查清单与手册编制1.8万元、功能性检查成本1万元、第三方可靠性测试 1.5万元、需求文档透漏“跨校成绩查询”功能返工1.5万元。代码逻辑错误重构0.8万元、上线后“课程冲突提醒”bug 紧急修0.6万元。
质量控制执行:需求阶段通过需求跟踪矩阵关联250条教务需求与测试用例，最终验证覆盖了242条需求；开发阶段累计编写代码5万行，单元测试与集成测试共发现18个软件缺陷，系统测试验收时，执行600条测试用例,通过了564条；针对“成绩统计模块数据计算偏差”缺陷，团队用鱼骨图定位原因为“数据库查询语句逻辑错误”，制定“优化SQL语句并增加数据校验逻辑”的纠正措施，验证后缺陷关闭，未影响项目上线时间。
质量持续改进:项目中期开展质量复盘会，分析出“需求评审参与人员不全”、“单元测试覆盖率仅80%”2个问题，随即补充教务主任参与后续评审，要求开发人员补充单元测试用例，使后期缺陷率下降30%。
【问题 1】（8 分）
结合案例，并参考示例，补充完整如下的本项目质量管理计划表。
|
组成部分 |
本项目中的具体内容 |
|
质量标准 |
《信息技术软件产品质量要求与评价》标准 |
|
质量目标 |
（1） |
|
（2） |
明确质量保证工程师、测试工程师、项目经理的具体质量职责 |
|
（3） |
需求基线评审、详细设计评审、单元测试验收、系统测试验收 |
|
项目使用的质量工具 |
（4） |
|
....... |
....... |
【问题 2】(6 分)
请分别计算本项目中的预防成本、评估成本和失败成本。
【问题 3】(4 分)
计算本项目的“需求覆盖率”和“软件缺陷率”，并判断是否达到项目质量目标。(结果保留两位小数)
答案：
【问题 1】
|
组成部分 |
本项目中的具体内容 |
|
质量标准 |
《信息技术软件产品质量要求与评价》标准 |
|
质量目标 |
（1）需求覆盖率>95%、软件缺陷率≤0.4个/千行代码、测试用例通过率>92%三项目标 |
|
（2）质量角色与职责 |
明确质量保证工程师、测试工程师、项目经理的具体质量职责 |
|
（3）为项目规划的质量控制和质量管理活动 |
需求基线评审、详细设计评审、单元测试验收、系统测试验收 |
|
项目使用的质量工具 |
（4）质量成本、鱼骨图、测试、核对单，质量复盘会、需求跟踪矩阵、缺陷跟踪工具MANTIS等 |
|
....... |
....... |
【问题 2】
预防成本：2.2万元(培训)+1.8万元(质量检查清单与手册编制)=4万元。
评估成本：1万元(功能性检查成本)+1.5万元(第三方可靠性测试)=2.5万元。
失败成本：1.5万元(需求文档透漏“跨校成绩查询”功能返工)+0.8万元(代码逻辑错误重构)+0.6万元(上线后“课程冲突提醒”bug紧急修复)=2.9万元。
【问题 3】
需求覆盖率=242/250=96.8%＞0.95%,达到质量目标
软件缺陷率=18/50千行=0.36个/千行代码<0.4个/千行代码，达到质量目标
试题三（17 分）
某大型制造集团公司启动了ERP系统升级改造至云平台的项目，旨在实现业务流程标准化、提升数据实时性和支持智能制造转型。
项目执行过程中，小李识别了干系人，将集团领导、财务部门领导、分厂综合办列为核心干系人，记入干系人登记册，并进行了如下沟通管理相关的活动。
活动1:项目初期，由于系统升级过程需要得到各个部门的大力支持，因此项目经理小李与集团领导汇报获批后，通过企业内网发布ERP系统升级通知。
活动2:小李重点走访了财务部门领导,在分析财务业务目前的困境与问题基础上收集了相应的需求，并带领团队经过多次会议讨论给出了相应的解决方案。
活动3:由于集团公司各分厂距离较远，沟通比较困难，小李通过邮件的方式通知分厂综合办,告知系统升级的优势，要求一周内安排业务骨干支持需求调研工作。两周后小李未收到分厂反馈，经微信沟通发现部分分厂长并未收到通知，收到通知的分厂长也由于生产进度紧张，担心新系统升级过程会影响工作进度，并未安排业务骨干参与需求调研的工作。
活动4:新产品进入开发阶段后，发现缺乏旧系统的逻辑接口说明，辗转找到负责维护旧系统的技术员，沟通时了解到他担心新系统上线后自己被取代而不愿意配合。给项目团队的开发造成很大阻力。
进入测试阶段，由于系统流程不符合生产实际操作，数据迁移频繁报错等，导致开发工作陷入停滞，预算超支，工期延误。
【问题1】(5 分)
分析案例，指出项目组在干系人管理和沟通管理方面出现的问题。
【问题2】(8 分)
结合案例,请分别写出 4 个沟通活动中涉及的干系人以及小李与各干系人沟通时分别采取的沟通方式。
【问题3】(4 分)
在识别干系人过程中，应用数据表现技术对干系人进行分类，分类方法有哪些?
答案：
【问题1】
干系人管理出现的问题
1. 干系人识别不全
2. 未对干系人进行分析，了解他们的期望，影响和作用
3. 未编写干系人参与计划，导致后续部分干系人的抵制
4. 未做监督干系人，出现问题后，未及时调整引导干系人参与的策略
沟通管理出现的问题
1. 未制定沟通管理计划
2. 沟通不及时、不充分，在项目早期未能与旧系统技术员进行有效沟通，也缺乏与一线业务操作人员的充分沟通，导致流程与实际脱节。
3. 沟通方式选择不当，针对距离较远的分厂，采用“邮件”这种单向推送的沟通方式 ，导致信息沟通不畅
4. 沟通内容不充分:向分厂沟通时，只强调了系统升级的“优势”，而没有主动提及和解决他们最关心的“影响和工作进度”的风险和顾虑，导致他们产生抵触情绪。
5. 缺乏有效的沟通跟进和反馈机制:发送邮件后“两周后未收到反馈”。
6. 缺乏跨部门沟通协调机制，未联动集团领导推动分厂配合需求调研。
7. 沟通信息不完整，未提前收集旧系统逻辑接口说明等关键资料。
8. 未针对不同干系人定制沟通内容，对财务部门有深入沟通但忽视分厂实际诉求。
【问题 2】
活动1：干系人是集团领导、各部门；集团领导沟通方式是互动式，各部门沟通方式是拉式沟通。
活动2：干系人是财务部门领导；沟通方式是互动沟通。
活动3：干系人是各分厂综合办、分厂厂长；各分厂综合办的沟通方式是推式沟通、分厂厂长的微信沟通是互动沟通（有一点争议）。
活动4：干系人是技术员；沟通方式是互动沟通。
【问题 3】
常见的分类方法包括作用影响方格、干系人立方体、凸显模型、影响方向和优先级排序等。
试题四(20 分)
A科技公司成功中标某高校的“智慧校园”综合管理平台项目，公司任命老王负责项目管理工作，并选派年轻工程师小陈担任配置管理员。在项目启动会上，小陈展示了根据公司模板编制的配置管理计划,但由于缺乏大型项目实战经验，该计划中的部分内容与实际项目需求存在脱节。
开发阶段，开发人员小李在实现“课表推送”功能时，发现需求文档针对该功能的描述不合理，他直接在受控库中修改了文档，并基于修改后的需求进行了开发。
测试阶段,产品经理发现“课表推送”功能实现与原始设计存在偏差，但已无法追溯需求文档的变更记录。
集成测试阶段,“成绩管理”模块集成测试频繁失败，调查发现受控库中具有依赖关系的数据库脚本与程序代码的版本不一致，一是因为两名开发人员分别在本地修改了同一个数据库脚本。二是由于未遵循配置库的变更及检出机制，修改后的数据库脚本提交到受控库中后出现了版本覆盖问题。临近交付，开始执行配置审计工作时，发现用户手册与系统功能存在多处差异。追溯发现，文档团队使用的仍是早期的基线版本,后续的变更都未能及时同步到文档库。
【问题1】(8 分)
请简述该项目在配置管理上存在的问题。
【问题2】(5 分)
针对数据库脚本与代码版本不一致的问题,请从配置管理的角度提出具体改进方案。
【问题3】 (4 分)
判断正误。
(1）配置库中的受控库允许开发人员直接修改配置项。（）
(2）配置状态报告应该包含每个配置项的变更历史记录。（）
(3）配置审计只需要在项目结束时进行。（）
(4）配置项的状态一般包括“草稿”、“正式”和“修改”三种状态。（）
【问题4】(3 分)
配置库通常可分为(1)、受控库和（2）三种类型。其中，包含已发布使用的各种基线的存档，并被置于完全
的配置管理之下的库是（3）。
答案：
【问题1】
1、小陈缺乏配置管理经验，无法有效进行配置管理。
2、配置管理计划没有基于项目的实际情况，不符合项目要求，只是单纯参考公司的模板
3、没有进行具体的配置项识别
4、小李直接在受控库中修改文档，没有遵守配置管理流程。
5、缺乏配置项追溯变更机制，需求文档后修改后没变更记录
6、未定期开展配置状态报告，未及时监控配置项版本变更情况和一致性。
7、没定期进行配置审计，只在临近交付时才做配置审计。
8、缺少配置管理回顾与改进
9、配置库权限管控不严，开发人员可直接修改受控库中的需求文档，未设置
权限隔离。
10、未建立配置项基线变更同步机制，文档团队未及时获取后续变更，仍使用
早期基线版本.
11、配置管理培训不足，开发人员、文档团队对配置管理流程和规范不熟悉。
【问题2】
根据题干给的原因：一是因为两名开发人员分别在本地修改了同一个数据库脚本。二是由于未遵循配置库的变更及检出机制，修改后的数据库脚本提交到受控库中后出现了版本覆盖问题。
主要围绕基于配置库的变更控制进行总结，
1、建立数据库脚本检出/检入强制流程，开发人员需从受控库检出脚本并锁定，修改后提交时触发版本控制，避免直接覆盖。
2、制定数据库脚本版本命名规范，包含修改人、日期、变更编号等信息，清晰区分不同版本。
3、执行提交前审核流程，数据库脚本修改后需经技术负责人审批，通过后方可提交至受控库。
4、定期开展配置项一致性检查，通过工具比对数据库脚本与程序代码的版本匹配度，及时发现偏差。
5、建立配置库操作日志审计机制，记录所有脚本的检出、修改、提交操作，便于追溯版本变更轨迹。
6、为开发人员提供配置管理规范培训，明确数据库脚本的变更流程、版本控制要求，避免违规操作。
【问题3】
× 受控库配置项需经变更流程审批，不允许开发人员直接修改
√ 配置状态报告需包含配置项变更历史，确保可追溯
× 配置审计应贯穿项目全生命周期，而非仅项目结束时
√ 配置项常见状态包括 “草稿”“正式”“修改” 三类
【问题4】
（1）开发库 （2）产品库 （3）产品库