简介这份《软件项目管理案例教程》第四版课后答案面向高校软件工程、项目管理课程学习者及备考人员用于对照教材章节核对练习、梳理核心概念与查漏补缺。压缩包内为1个docx文件约1.1MB按教材章节目录组织包含填空题、判断题、选择题和问答题等题型并附参考答案便于按章节定位复习。内容覆盖项目管理定义与五大过程组、项目特征、敏捷开发四价值观与十二原则、PMBOK十大知识领域、Gantt图与PERT图等工具技术以及项目立项、项目章程、甲乙双方职责等要点其中还包含自制或购买决策等计算分析题可帮助读者理解解题过程而非只记结论。目前已有5432人学习适合课堂作业核对、期末复习和项目管理基础知识体系梳理。1. 项目管理的地图五个过程组、十个知识域与一条隐藏主线很多人翻开这份软件项目管理案例教程的课后答案第一反应是把它当题库背填空、判断、选择、问答四类题型一网打尽。可照这个路子复习两章之后就会乱——因为十二章不是十二个并列专题而是一条从立项到收尾的流水线。五个过程组启动、计划、执行、控制、收尾是横轴PMBOK 的十个知识域是纵轴中间挂着需求、WBS、估算、进度、质量、配置、团队、风险八个可计算模块。看懂这张坐标图再看判断题会发现多数错误选项都踩在同几个概念边界上临时性与永久性、预测型与适应型、质量保证与质量控制。这份笔记按这条主线把十二章重排一遍适合系统学这门课的人也适合考前拿着答案快速查漏补缺。2. 立项与生存期模型从项目章程到瀑布、V、敏捷的分野立项和选模型在教材里分属两章考题却常混在一道题里考。原因很实在立项回答「这个项目要不要做、由谁授权、边界在哪」生存期模型回答「做的时候按什么节奏推进」。前者决定项目的合法性后者决定项目的可控性。把这两块放在一起看很多判断题的错误选项恰恰是把「立项阶段该产出的文档」和「计划阶段该产出的文档」调了个位置或者把「需求明确的项目该用 V 模型」写成了「该用快速原型」。下面按立项三件事、模型选择、敏捷原则三层拆开。2.1 立项要钉死的三件事与 make-or-buy 决策立项阶段的核心产出是把三件事说清楚项目的目标、时间表、使用的资源和经费并且拿到项目发起人的认可。注意是发起人不是项目经理——判断题里「项目立项需要获得项目经理的认可但不需要项目发起人的认可」是典型的送分错项。围绕这三件事立项阶段会衍生出两个文档项目建议书和项目章程。项目建议书是项目初始阶段开发的文档不是计划阶段。项目章程则是项目执行组织高层批准的一份书面签署文件用来确认项目存在。它的内容要记牢三块对项目的确认、对项目经理的授权、项目目标的概述。选择题最爱问「以下哪项不包括在项目章程中」标准答案是「对项目风险的分析」——风险分析是后续风险管理过程的事立项阶段只做粗粒度的可行性判断。招投标阶段的甲乙双方任务分配是第二章最容易张冠李戴的地方直接列表对照任务甲方需求方乙方供方/卖方招投标阶段招标书定义、供方选择、合同签署项目分析、竞标、合同签署高频干扰项「编写建议书」是乙方的事「招标书定义」不是乙方的活还有一个常被忽略的前提项目招标不是必需的。判断题「项目招标对于一个项目的开发是必需的即便项目是内部项目」为错内部项目完全可以走直接立项。乙方即供方为顾客提供产品或服务的一方软件项目合同里甲方是需求方乙方是供方这两条属于必须条件反射的常识。立项之后紧接着是 make-or-buy 决策也就是「自造—购买」决策用来确定待开发产品的哪些部分采购、哪些外包、哪些自主研发。这里的 make 只指自主开发不包括外包判断题「make 指的只是自主开发」为正确。教材里的经典计算题值得完整走一遍自制方案一次性投入 30000 元、每月维护 3500 元购买方案一次性 18000 元、每月维护 4200 元。先算制造差额 30000−1800012000 元再算月维护差额 4200−3500700 元临界月份12000÷700≈17.14 个月。结论不是「自制更便宜」或「购买更划算」而是分段的产品生命周期在 17 个月以内选购买超过 17 个月选自造。这类题的失分点几乎全在「只比一次性投入、忘了维护费的差额方向」。与立项配套的还有 PMI 人才三角三个关键技能是技术项目管理、领导力、战略和商务管理。选择题会拿「测试能力」来凑第四个选项记住三角只画三条边就够了。2.2 预测型与适应型六种生存期模型的判断依据总体上项目生存期模型可以分成预测型和适应型两类。预测型以瀑布、V 模型为代表假设需求在前期可以基本锁定适应型以敏捷各流派为代表假设需求会持续变化。命题人最喜欢在「适用条件」和「反向表述」上做文章下面这张对照表基本覆盖了第三章的选择题模型适用条件典型判断句瀑布模型需求明确、方案明确、无重大变化「瀑布不适合短期项目」是错的短期项目反而可用V 模型需求明确、方案明确且安全与性能要求严格航天控制系统、财务系统这类场景增量式模型需求较明确但要分摊投资风险可避免一次性投入过大快速原型项目初期需求不明确需减少不确定性需求模糊时优先考虑迭代模型需求变化大需要多次提交与反馈「不多次提交」是错的Scrum / XP / DevOps需求持续变化、团队规模小、要快速反馈都属于敏捷都是自适应过程几个细节值得单独标记。瀑布模型要求所有活动严格按顺序执行一个阶段的输出是下一个阶段的输入这一点和 V 模型同属预测型判断题里「瀑布模型和 V 模型都属于预测型生存期模型」为正确。增量式模型的价值不在于应对需求变化而在于把一次性大投入拆成多次小投入从而降低资金风险。迭代模型的正向描述是「不断反馈原型、加快开发速度、适合需求变化大」负面描述「不多次提交」一定错。XP 极限编程从 3 个层面提供了 13 个敏捷实践实践原则常考四条快速反馈、假设简单、包容变化、增量式改进「详细设计」不在其中这是选择题的固定陷阱。DevOps 是 Development 和 Operations 的组合把开发与运维的边界打通它不是独立于敏捷之外的新模型而是敏捷在交付链路上的延伸。至于混合模型定义很朴素把几种不同模型组合起来允许一个项目沿着最有效的路径发展也叫过程开发模型。2.3 敏捷的四个价值与 12 原则的考法敏捷模型包括《敏捷宣言》的价值观、12 个原则以及一些通用实践。四个核心价值对应 12 个敏捷原则这个数字关系是填空题的原题。四条价值观要能默写个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划。考题的阴险之处在于把「敏捷开发过程是自适应的过程」塞进选项让你判断它是不是宣言内容。它不是——这是对敏捷特征的描述四条价值里没有这一条。同样容易混的是敏捷和预测型的关系敏捷属于自适应过程不是「预测型和迭代型的混合模型」后者是对混合模型的描述被挪过来当干扰项。12 原则不必逐字背但要有分组印象尽早并持续交付有价值的软件、欢迎需求变化、频繁交付可工作的软件、业务人员与开发人员日常协作、以有积极性的个体为核心、面对面沟通、可工作的软件是进度的主要度量、可持续的开发节奏、持续关注技术卓越与良好设计、简单性、自组织团队、定期反思与调整。这套原则落到管理方式上就是敏捷项目采取仆人式管理管理者为团队服务而不是发号施令落到需求上就是敏捷项目主要用用户故事描述需求而不是动辄几百页的需求规格说明书。3. 需求到估算范围、WBS 与成本的三级传递第四章到第六章在教材里是三个独立章节实际上是一条传递链需求决定范围范围决定 WBSWBS 决定估算的颗粒度。这条链断在哪一环后面的成本和进度都会失真。复习时如果只背「需求管理有五个过程」「WBS 最底层是工作包」做题能应付填空但一到问答题和计算题就会露怯。下面把这条链上的三个节点拆开每个节点都给出可对照的判断标准。3.1 需求管理五过程与需求规格说明书需求管理包括五个过程需求获取、需求分析、需求规格编写、需求验证、需求变更。选择题会把最后一个换成「需求更新」这是错的——变更强调的是受控的修改流程更新只是动作描述。需求本身的定义也要准确用户对软件的功能和性能的要求即用户希望软件能做什么事、完成什么功能、达到什么性能。功能性需求与非功能性需求的分界是判断题重灾区。「软件项目系统的响应时间属于功能性需求」为错响应时间、并发量、可用性都属于非功能性需求。另一道高频错题是「需求分析工作完成的基本标志是形成了一份完整的、规范的需求规格说明书」答案同样为错需求是逐步演进并被持续验证的一份文档的完成不等于分析工作收口这个判断在敏捷语境下更明显。需求规格说明书本身可以包括系统的运行环境这条判断题是正确的——很多人凭直觉认为规格书只写功能把运行环境划给设计文档结果翻车。需求变更是软件项目的一个突出特点可以导致项目范围蔓延这句话几乎每年以不同形式出现。到了敏捷项目里需求的主要载体变成用户故事英文 user story不使用技术语言描述常常写在卡片上再贴到墙上一个 Epic 还可以继续分解成若干用户故事。选择题问「敏捷项目需求一般采用下面哪种描述」答案是用户故事不是用例、不是 DFD、也不是数据字典。3.2 结构化方法与 UML 需求视图的分工结构化方法这一支要记三样东西数据流图 DFD、数据字典、系统流程图。系统用例图属于 UML 阵营不属于结构化方法设计这是选择题的固定搭配。数据流分析方法是一种自顶向下、逐步求精的分析方法判断题把它写成「自下而上」就是错的。数据字典的组成也要精确数据项、数据流、数据文件、处理加工。常见干扰项是「数据库」和「操作指令」前者是存储实体不是字典条目后者是把处理过程换了个说法。数据字典的作用是给 DFD 里的每个成分下定义让图能被人读懂而不是描述数据库表结构。UML 需求视图常考三种图用例图、状态图、顺序图。甘特图是进度管理工具不是需求视图这是最常被塞进来的假选项。用例图的读图题一般考两问参与者是什么角色、写出至少三个用例。以课务管理系统为例参与者是学生用户用例包括登录、注册、选课。答这类题的关键是把「参与者」写成角色名而不是具体人把「用例」写成动词短语而不是功能模块名。3.3 WBS 的分解方法与工作包验证WBS 全称 Work Breakdown Structure中文叫任务分解结构。任务分解的本质是把一个项目分解成更多的工作细目或子项目让项目变得更小、更易管理、更易操作从而提高成本、时间和资源估算的准确性让责任分工更明确。WBS 最底层的可交付成果是工作包 work package最高层不是工作包——这条判断几乎必考。创建 WBS 有四种方法两两成对考法就是让你判断方向方法方向适用场景自顶向下从一般到特殊从项目大局逐层细化开发人员对项目熟悉、对大局有把握自底向上从特殊到一般先定义特殊任务再组织成高层没做过的全新项目模板参照套用同类项目的历史 WBS有成熟模板可复用类比参照相似项目的分解结构缺乏直接经验但有可比项目方向搞反是最高频的失分点熟悉的项目用自顶向下全新项目用自底向上判断题会故意写成「熟悉项目最好用自底向上」这是错的。WBS 的验证标准也要背准四条最底层要素是否是实现项目目标的充分必要条件最底层要素之间是否有重复最底层要素是否有清晰完整的定义每个工作包是否有唯一责任人。选择题问「检验 WBS 分解结果的标准不包括哪一项」答案往往是「分解的层次不少于 3 层」——层数不是标准颗粒度到位才是。另外几条容易被忽略的结论WBS 提供了项目范围基线不在 WBS 中的任务就不属于该项目的工作一个工作包可以分配给另一个项目经理去完成每个具体细目通常指定唯一的编码WBS 的结构是分级的树形结构不是分层集合、线性结构或图状结构。3.4 成本估算方法与三点估算公式软件项目成本分直接成本和间接成本项目人力成本归属于直接成本间接成本则是与具体项目不直接相关的分摊成本。规模是成本的主要因素也是成本估算的基础这条结论决定了后面所有估算方法都围绕「先估规模、再折算工作量」展开。常见估算方法与适用场景方法计量单位或公式适用场景代码行 LOC源代码长度有历史数据、技术栈稳定功能点 FP5 类功能组件项目早期、与语言技术无关类比法参照历史项目项目初期、信息不足COCOMOa×(KLOC)^b×F已有规模估算需折算人月三点估算(a4mb)/6不确定性大需区间Delphi 专家估算多专家独立三值估算再平均缺历史数据故事点Fibonacci 序列敏捷项目用例点角色、场景、技术与环境因子用例驱动开发功能点方法要记 5 类功能组件的计数项外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件。选择题会把「内部输出」塞进来当第六项这是编造项。功能点估算与项目所使用的语言和技术无关判断题写成「有关」即为错——这正是功能点相对代码行的最大优势。故事点估算是相对的估算过程注册功能 3 个故事点成绩录入工作量略多按 Fibonacci 等级下一档就是 5 个故事点而不是 4 或 6。用例点方法则通过分析用例角色、场景以及技术与环境因子来做估算。三点估算和 COCOMO 的公式必须能动手算下面这段代码把两道经典题一起跑了# 三点估算 COCOMO 中等模型的工作量与费用 def pert(a, m, b): # a 最乐观值、m 最可能值、b 最悲观值 return (a 4 * m b) / 6 # 三位专家的三值估算单位万元 experts [(2, 7, 12), (4, 6, 8), (2, 6, 10)] each [pert(*e) for e in experts] cost sum(each) / len(each) print(each, round(cost, 2)) # [7.0, 6.0, 6.0] 6.33 def cocomo(kloc, a3.0, b1.12, f1.0): # a、b 为模型系数f 为所有属性乘子的连乘结果 return a * (kloc ** b) * f effort cocomo(50, f1.3) # 半嵌入型中等模型仅可靠性取 1.3 print(round(effort, 2), round(effort * 2, 2)) # 311.82 623.64先说 pert 函数它把三个估计值按 1:4:1 加权Delphi 方法则是每位专家各算一次 pert再把专家结果取算术平均两级平均不能合并成一步。再说 cocomo 函数a 和 b 由项目类型决定中等规模半嵌入型取 a3.0、b1.12f 是所有成本驱动属性乘子的连乘教材这道题只有可靠性取 1.3其余取正常值 1所以 F1.3。算完工作量 311.82 人月乘以 2 万元/人月得到 623.64 万元。另一类题走 IBM 模型C 语言约 150 LOC/FP85 个功能点折合 12750 行即 12.75 KLOC再依次套 E5.2×L^0.91、D4.1×L^0.36、S0.54×E^0.6、DOC49×L^1.01四个公式各有各的量纲人月、月、人、页不能串。成本预算的目的则是产生成本基线它和估算的区别在于估算是「大概要花多少」预算是「每个时间段每个工作单元分到多少」。选择题问「每个时间段中各个工作单元的成本」答案是预算而不是估算。4. 进度、质量、配置与风险执行期的四条控制线计划做完项目进入执行真正拉扯精力的是四件事进度能不能压、质量由谁负责、变更怎么受控、风险怎么兜底。这四块在教材里分属第七到第十一章考点密度最高计算题也基本集中在这里。复习时建议按「图—公式—角色—策略」四件套来记每种控制线都有一张图、一组公式、一批角色和一个应对策略清单。4.1 网络图、关键路径与 PERT 概率关键路径决定了项目在给定金钱和资源条件下完成所需的最短时间。时间是一种特殊的资源以单向性、不可重复性、不可替代性区别于其他资源也是项目计划中灵活性最小的因素这几句话是填空题的常客。两种网络图要分清ADM 箭线图中箭线表示活动或任务节点表示事件PDM 前导图中节点表示活动箭线表示任务之间的逻辑关系。任务之间的关系有四种——结束-开始 FS、开始-开始 SS、结束-结束 FF、开始-开始-结束不没有这一种选择题里的「结束-开始-结束」是编造的第四种关系。依赖关系分三类强制性依赖硬逻辑如编码完成才能测试、软逻辑依赖团队偏好决定、外部依赖项目与非项目活动之间。判断题把「外部依赖关系又称强制性依赖关系」写成正确就是故意混淆两个维度。公式部分必须条件反射EFESdurationLSLF−durationTFLS−ESLF−EF。总浮动决定进度的灵活性浮动不是「不增加成本就能延迟的时间」而是不影响项目完工的前提下可延迟的时间量。关键路径会随进度变化而改变判断题「项目进行过程中关键路径是不变的」为错。时间压缩只有两条路应急法赶工和平行作业法快速跟进。赶工要在关键路径上挑选成本最低的活动来压选非关键路径上的活动等于白花钱这是选择题的经典陷阱。平行作业法把串行任务改为并行能压缩工期但会放大返工风险。Lag 会延长项目进度Lead 会缩短方向别记反。PERT 的三点估算公式是 (O4M4? 不(O4MP)/6标准差 δ(P−O)/6再用正态分布的经验概率±1δ 约 68.3%±2δ 约 95.5%±3δ 约 99.7%。问答题里「先算 E 和 δ再判断区间落在几个 δ 内」是固定套路能不能拿满分取决于有没有把「区间半宽对应几个标准差」写清楚。import math def pert(o, m, p): # o 乐观值、m 最可能值、p 悲观值 e (o 4 * m p) / 6 sd (p - o) / 6 return e, sd def prob_within(e, sd, target): # 单侧区间概率落在 [e-sd, target] 内的比例 z (target - e) / sd return 0.5 0.5 * math.erf(z / math.sqrt(2)) e, sd pert(6, 12, 24) print(e, sd) # 13.0 3.0 print(prob_within(e, sd, 16)) # 约 0.841 # 三段串联任务EE1E2E3方差相加再开方 e1, s1 pert(2, 3, 6) e2, s2 pert(4, 6, 8) e3, s3 pert(3, 4, 6) e_total e1 e2 e3 sd_total math.sqrt(s1**2 s2**2 s3**2) print(round(e_total, 2), round(sd_total, 2)) # 13.5 1.07 print(prob_within(e_total, sd_total, 14.57)) # 约 0.841代码里有两个容易写错的地方。第一串联任务的总标准差不是各段标准差相加而是方差相加后开方直接相加会把区间放得太宽。第二问「在 14.57 天内完成的概率」实际求的是从负无穷到 14.57 的累积概率落在均值左侧的一半要算进去所以结果是 50% 加上单侧 34.15% 得到 84.15%只报一个 68.3% 会被扣分。进度图也要对应上甘特图显示任务工期、开始时间、结束时间以及资源信息里程碑图只标关键节点燃尽图表示敏捷项目的进度和剩余任务燃起图的方向相反。4.2 质量保证与质量控制的边界质量的经典定义是「满足要求的程度」既包括符合规定的要求也包括满足客户隐含的需求。软件质量则是软件满足明确说明或者隐含需求的程度。两条判断题专门打脸直觉软件质量不能通过后期测试得以提高软件质量也不是「代码正确的程度」。测试只能发现问题质量是设计和过程里长出来的。质量成本包括预防成本和缺陷成本注意是缺陷成本不是「缺失成本」。质量管理过程只有三个质量计划、质量保证、质量控制选择题用「质量优化」凑第四个一眼排除。McCall 质量模型关注三个方面产品运行、产品转移、产品修改「产品特点」是编造项。其他质量模型还有 Boehm 模型和 ISO 系列模型看到「Mark 质量模型」直接判定为假。质量保证和质量控制的区别是本章最值得列表记忆的一组维度质量保证 QA质量控制 QC对象项目实施过程项目产品可交付成果手段过程审计、过程改进检查、抽样、缺陷纠正实施者质量保证部门人员开发人员为主作用建立信心间接提高质量直接提高产品质量主要活动项目执行过程审计、项目产品审计按质量要求核对具体成果教材的表述里有一句容易看反「质量保证是后期质量活动质量控制是前期质量活动」这说的是两者在项目生命周期中发挥作用的时点差异不是流程顺序背诵时建议直接记住「QA 管过程、QC 管产品」这八个字。质量计划的方法包括质量成本分析、因果分析图鱼骨图、基准对照抽样分析不属于质量计划方法它是质量控制阶段降低检验成本的手段。质量控制非常重要但也要成本使用抽样统计可以降低质量控制的成本这条结论在选择题里反复出现。敏捷项目的质量实践包括结对编程、TDD、迭代评审、持续集成「需求规格编写过程审计」是传统质量保证的动作不是敏捷实践。4.3 配置管理与基线变更链软件配置管理的核心功能是完整性和可跟踪性它无法确保软件产品的正确性——正确性靠测试和评审配置管理保证的是「每个版本都能找得到、每个变更都能追得到」。这条边界清理干净后面几个判断题就不会错。基线标志开发过程中一个阶段的结束和里程碑一个或一些配置项形成并通过审核即形成基线。基线不是不可修改的而是必须通过基线变更控制流程处理变更控制需要关注的是标识变更、提出变更、管理变更而不是阻止变更。基线变更必须经过 SCCB 授权SCCB 全称软件配置控制委员会职责包括评估变更、批准变更申请、在生存期内规范变更申请流程、对变更进行反馈、与项目管理层沟通「提出变更申请」不是它的职责这是选择题的固定选项。基线变更控制有四个步骤顺序不能乱变更请求 → 变更控制评估→ 变更批准/拒绝 → 变更实现。配置管理的基本过程有六项配置项标识与跟踪、配置管理环境建立、基线变更管理、配置管理审计、配置状态统计、配置管理计划。常见配置项可以按阶段列一串软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书、源代码清单、测试计划、测试用例与实验结果、可执行程序、用户手册、维护文档。配置管理中最典型的三类问题是找不到某个文件的历史版本、开发人员未经授权修改代码或文档、异地协同开发导致版本变更混乱「甲乙双方在资金调配上存在意见差异」是合同与财务问题不是配置管理问题。持续交付场景下的配置管理有一条补充结论强调对项目的所有相关产物及其之间的关系都进行有效配置管理更倾向于使用基于主干的开发模式而不是长期分支。4.4 团队结构、沟通渠道与风险应对组织结构只有三种特点与适用场景要成对记类型特点适用场景职能型充分发挥部门资源优势线性管理主要由一个部门完成、技术比较成熟的项目项目型项目经理掌握资源成员归属感弱、缺乏安全感项目独立性强、需要快速决策矩阵型双重汇报、资源共享项目经理与职能经理分权涉及多领域、跨部门的项目选择题里「在哪种组织结构中项目成员没有安全感」答案是项目型「适用于主要由一个部门完成的项目」答案是职能型「涉及多领域和特性」答案是矩阵型。沟通渠道数量公式是 n(n−1)/220 个人最多 190 条渠道。人员从 5 人扩到 8 人渠道从 10 条变 28 条增长 2.8 倍而不是 2 倍——这类题算错基本都是拿人数比直接相除。沟通渠道不是越多越好应尽量少而有效。项目经理花在沟通上的时间占 75%90%这个比例高得反直觉但它是本章最常考的数字。沟通的基本原则是及时性、准确性、完整性和可理解性编制沟通计划的基础是沟通需求分析。沟通方式可以按五个维度分类书面与口头、语言与非语言、正式与非正式、单向与双向、网络沟通。重要信息用书面紧急信息用口头复杂问题用会议解决重要内容还要多种方式叠加——邮件加电话提醒、加回执、加会议传达单一渠道不算有效沟通。敏捷团队一般 39 人集中在一个场地、可以围坐本文还有配套的精品资源点击获取