习题课主要围绕选择题和案例分析题展开，考查方式不是单纯背定义，而是要求把 软件项目管理过程、任务分解结构WBS、进度计划、成本计划、质量计划、风险计划、项目合同、核心计划执行与控制 等知识放到题干场景中判断。对应练习见 习题课模拟题与解析。
题型结构 重点
- 选择题：考查概念辨析、过程输入输出、常见方法适用场景、英文项目管理术语。
- 案例分析题：考查项目失控原因分析、改进措施、计算题、网络图、关键路径、WBS 与进度计划问题。
- 计算题：集中在挣值分析、关键路径、总时差、自由时差、进度压缩。
- 综合管理题：要求从人员、过程、工具、计划、控制、沟通、风险等角度找问题。
选择题知识点
开发方法辨析
- 严格区分阶段、每个阶段有明确任务和成果、强调整体性和顺序性、文档标准化，对应结构化方法。
- 题干如果强调快速反馈、迭代、客户参与、响应变更，通常关联敏捷方法和 需求管理 中的敏捷需求。
软件质量属性
- 提高系统可靠性的典型措施是设置备用模块、冗余设计、故障切换。
- 界面升级主要改善易用性或用户体验，不直接等同于可靠性提升。
- 质量测量指标应是可量化的质量目标，如缺陷密度、可靠性、可用性、响应时间等，不能把市场占有率这类商业指标误认为 质量计划 指标。
政府采购与合同
- 公开招标、邀请招标、单一来源采购等采购方式需要结合条件判断。
- 采购对象规格统一、现货充足、价格变化小的场景通常适合询价采购。
- 只有少量供应商能够提供特殊货物或服务时，可能适用邀请招标。
- 合同和采购题常与 项目合同、辅助计划执行与控制 中的合同管理连接。
可行性研究
- 初步可行性研究关注项目是否值得继续深入论证，常涉及技术、经济、社会、组织、风险等方面的初步判断。
- 投资与成本估算属于可行性分析中的重要内容，可与 项目立项与可行性研究 和 成本计划 连接。
项目章程
- 项目授权与章程 应由项目团队之外的发起人或组织高层发布。
- 项目章程将项目与执行组织日常运营和战略目标联系起来。
- 项目章程可包含业务论证、项目目的、主要需求、关键干系人、总体里程碑等内容。
- “项目章程不包括干系人的需求和期望”这类说法通常是错误项。
组织结构
- 项目经理负责制、目标明确、项目经理对整体资源控制力强、跨职能协调难度降低、团队归属感强，通常对应项目型组织。
- 职能型组织中项目经理权力弱，资源由职能部门掌握。
- 矩阵型组织介于职能型和项目型之间，常考弱矩阵、平衡矩阵、强矩阵的权力差异。
范围确认
- 核心计划执行与控制 中的范围确认关注可交付成果是否被正式接受。
- 组织客户交付签字、第三方检验报告、确定正式接受标准，均可与范围确认相关。
- 审查变更请求以进行缺陷补救更偏向范围控制、变更控制或质量控制，不属于典型范围确认工作。
活动依赖关系
- 天气、法规、外部审批、供应商交付等来自项目外部的因素，属于外部依赖关系。
- 必须按技术逻辑先后完成的是强制性依赖关系。
- 项目团队基于经验或偏好设置的顺序是可斟酌处理的依赖关系。
质量成本
- 因质量问题导致返工、重新测试，属于内部失败成本。
- 因质量问题丧失承接其他项目机会，属于机会损失，可放入不一致成本或质量问题引发的间接损失分析。
- 质量成本题要先判断是预防成本、评估成本、内部缺陷成本还是外部缺陷成本。
关键路径法
- 进度计划 中的关键路径是网络图中决定总工期的最长路径。
- 关键路径可能不止一条，也可能随项目执行变化。
- 关键路径上的活动延误通常会导致总工期延误。
- 非关键路径活动延误不超过总时差时，项目总工期不受影响。
自下而上估算
- 自下而上估算先估算工作包或详细活动，再汇总到高层级。
- 优点是准确性较高，便于报告和跟踪。
- 缺点是费时费力，要求已经掌握较详细的项目范围。
- 对项目情况了解较少时，不适合优先使用自下而上估算。
挣值指标解释
- ，表示单位实际成本创造的预算价值。
- 表示每花费 100 元实际成本，获得 105 元预算价值，成本绩效较好。
- CPI 只说明成本绩效，不说明进度提前或落后；进度应看 。
项目控制英文题
- 项目控制中，项目经理要识别变更已经发生、确保变更被同意、管理变更过程。
- “确保所有变更都由管理层批准”不一定正确，因为变更应按变更控制流程和授权层级处理，不是所有变更都必须由最高管理层批准。
- 该类题要回到 配置管理计划 的变更控制和 项目集成计划 的整体变更控制。
案例分析题型
项目失控原因分析 重点
常见题干特征：高级项目经理因人手紧张，从技术骨干中选择子项目经理，子项目经理同时承担编程工作，最终导致子项目失控。
答题角度：
- 人员问题：项目经理角色任命不当，技术高手不一定具备项目管理能力；一人兼任项目经理和核心开发，角色冲突明显。
- 授权问题：任命项目经理前没有明确授权、职责、汇报关系和考核标准。
- 计划问题：缺少子项目计划，或未细化范围、进度、成本、质量、风险、人力安排。
- 监控问题：缺少里程碑跟踪、绩效报告、偏差分析和纠偏措施。
- 沟通问题：上级项目经理对子项目沟通不足，未建立例会和问题升级机制。
- 风险问题：没有提前识别人手不足、关键人员兼职、技术骨干管理经验不足等风险。
相关知识点：人力资源计划与沟通计划、辅助计划执行与控制、风险计划、项目集成计划。
如何避免子项目失控
- 任命前评估候选人的管理能力、技术能力、沟通能力和时间投入。
- 明确子项目经理职责、权限、目标、交付物和汇报机制。
- 为新任子项目经理提供项目管理培训或导师支持。
- 避免让子项目经理承担过多编码工作，减少角色冲突。
- 建立子项目计划，覆盖 WBS、进度、成本、质量、风险、沟通。
- 建立里程碑评审、周报、问题清单、风险清单和变更控制机制。
团队角色与团队管理
典型系统集成项目团队角色包括：
- 项目经理
- 系统架构师或技术负责人
- 需求分析人员
- 设计人员
- 开发人员
- 测试人员
- 配置管理员
- 质量保证人员
- 实施与运维人员
- 商务、采购、合同或客户接口人员
团队管理活动包括：
- 组建项目团队：获取人员、明确角色、建立责任分配矩阵。
- 建设项目团队：培训、团队建设、激励、建立信任。
- 管理项目团队：跟踪绩效、反馈、冲突管理、问题解决。
挣值计算题 重点
常见设问
- 计算成本偏差 。
- 计算进度偏差 。
- 计算成本绩效指数 。
- 计算进度绩效指数 。
- 根据 PV、AC、EV 画预算成本、实际成本、挣值曲线。
- 判断项目成本节约或超支、进度提前或落后。
公式
判断规则
- ：成本节约；：成本超支。
- ：进度超前；：进度落后。
- ：成本绩效好；：成本绩效差。
- ：进度绩效好；：进度绩效差。
习题课示例
题目给出预算成本、实际成本和挣值，答案页按 、、 计算：
结论：成本超支，进度落后。
网络图与关键路径题 重点
常见设问
- 填写每个活动的最早开始时间 ES、最早结束时间 EF。
- 填写最晚开始时间 LS、最晚结束时间 LF。
- 找出关键路径。
- 计算某活动总时差和自由时差。
- 判断项目能否在指定工期内完成。
- 提出缩短工期的方法。
计算步骤
- 正推计算 ES 和 EF。
- 反推计算 LS 和 LF。
- 计算总时差：。
- 计算自由时差：。
- 总时差为 0 的路径通常是关键路径。
习题课示例
- 活动时间结果示例：A 为 0-5，B 为 5-13，C 为 5-20，D 为 20-35，E 为 35-45。
- 关键路径为 A-C-D-E。
- B 的总时差为 7，自由时差为 7。
- C 的总时差为 0，自由时差为 0。
- 关键路径总工期为 45 天，因此不能在 40 个工作日内完成。
缩短工期措施
- 赶工：增加资源、加班、投入更多人员，重点压缩关键路径活动。
- 快速跟进：调整逻辑关系，使原本串行的活动并行执行。
- 降低活动范围或要求，但需要经过范围变更控制。
- 改进方法或工具，提高生产率。
- 优化资源配置，减少关键活动等待时间。
缩短工期必须同步评估对 成本计划、质量计划、风险计划 和 配置管理计划 的影响。
WBS 与进度失控案例
常见题干特征：项目经理组织制定 WBS，并根据以往经验制定进度计划。计划中包含需求分析、系统设计、编码、测试、综合布线、网络设备安装、试运行、验收等活动。项目执行中较早发现系统设计已落后，推测后续里程碑无法按期完成。
答题角度：
- WBS 分解可能过粗，没有分解到可管理、可估算、可跟踪的工作包。
- 进度计划过度依赖以往经验，没有结合本项目范围、资源、约束和风险重新估算。
- 活动之间的依赖关系可能不完整，例如需求、设计、编码、测试、布线、网络联调之间缺少清晰逻辑。
- 缺少里程碑检查点和阶段评审，导致偏差发现后纠偏困难。
- 对关键路径和资源冲突分析不足。
- 对春节、人员可用性、外部供应商、设备采购等风险考虑不足。
- 发现偏差后应进行进度控制、风险再评估、必要时提交变更请求。
相关知识点：任务分解结构WBS、进度计划、风险计划、核心计划执行与控制。
项目管理经验类知识点
习题课提到的项目管理经验可以作为案例题的改进措施素材：
- 项目经理应抓大放小，重点控制关键里程碑。
- 精通业务，准确把握关键需求，可用原型系统澄清问题。
- 建立 PM、CM、Bug Tracking 等全生命周期管理机制。
- 熟练使用项目管理、需求、设计、原型、配置管理、开发、测试工具。
- 建立常见问题列表和解决方案，多维度暴露风险和问题。
- 掌握常用框架、方案和设计模式。
- 重视变更管理，尤其是难缠的变更。
- 使用每日构建、小步快走降低集成风险。
- 重视软技能、团队激励和冲突管理。
NASA SEL 成功项目经验
应做事项
- 建立并遵循软件开发规划。
- 授权项目人员。
- 简化官僚体系。
- 定义需求基线，管理需求变更。
- 采取阶段性评估项目并及时修正项目规划。
- 定期重新评估系统规模和进度。
- 确定并管理阶段变化。
- 培养团队精神。
- 以少数资深人员开始项目。
不应做事项
- 不要让团队成员以非系统化方式工作。
- 不要确定不合理目标。
- 不要做没有认可的变更。
- 不要增加花哨功能。
- 不要人浮于事，尤其是项目初期。
- 不要假设阶段中期的时间延误可以在后期自然弥补。
- 不要随意降低成本标准或缩短时间。
- 不要假设大量文档一定能保证成功。
这些经验与 需求管理、配置管理计划、进度计划、风险计划、人力资源计划与沟通计划 直接相关。
答题模板
找问题题
- 人员：角色是否匹配，职责是否清晰，资源是否足够。
- 计划：是否有 WBS、进度、成本、质量、风险、沟通等计划。
- 过程：是否遵循启动、计划、执行、监控、收尾过程。
- 控制：是否有里程碑、绩效报告、偏差分析、纠偏措施。
- 变更：是否走正式变更控制，是否更新基线。
- 风险：是否识别、分析、应对、监控风险。
- 沟通：是否建立例会、报告、升级和干系人沟通机制。
提措施题
- 补计划：完善 WBS、进度、成本、质量、风险、沟通计划。
- 建机制：建立变更控制、配置管理、问题管理、风险跟踪机制。
- 强监控：设置里程碑、周报、评审、偏差分析。
- 调资源：补充人员、明确责任、培训或更换不合适人员。
- 控范围：确认需求和范围基线，防止范围蔓延和镀金。
- 管风险：建立 Top 10 风险清单并定期复审。
- 促沟通：强化项目经理、团队、客户、供应商之间的信息同步。