企业官网建设流程全解析

简介：这份《软件项目管理案例教程（第四版）》课后答案文档，面向高校软件工程、项目管理课程学生及备考项目管理相关考试的学习者，用于对照课后填空、判断、选择与问答题，快速核对答案并梳理章节核心概念。内容围绕项目管理定义、启动—计划—执行—控制—收尾五个过程组、项目目标性与临时性等特征展开，同时覆盖敏捷开发四项核心价值与十二条原则、PMBOK十大知识领域、立项与项目章程、甲方乙方及招投标、自制或购买决策等高频考点，兼顾概念辨析与简答思路。压缩包内共1个docx文件，约1.1MB，按章节组织题目与参考答案，便于检索和打印复习。已有5432人学习下载，适合需要系统刷题、查漏补缺或课堂对照的学生与初、中级项目管理人员使用。

1. 从“项目 vs 日常运作”这个反直觉考点切入

软件项目管理这门课的卷子有个很反直觉的地方：真正拉开分差的不是你能不能背出项目管理知识体系的十个领域，而是那些只有一句话的判断题——“项目可以重复进行”“关键路径在项目过程中不变”“基线产品不能修改”。这些题看着像送分，实际是送命，因为每一道都卡在概念的边界上。整份卷子的结构一般是填空、判断、选择、问答加计算，判断和选择加起来接近一半分值，而它们的考点高度集中在三组边界：项目与日常运作差在哪、预测型和适应型怎么分、质量保证和质量控制谁管过程谁管产品。这份《软件项目管理案例教程》第四版的课后答案，把十二章的题目按“考点—原题—答法”重新排了一遍，适合正在刷课后题、准备期末卷或者要过项目管理类笔试的人。下面从最容易被扣分的地方开始讲。

2. 总论与立项：五个过程组、十个知识域的题眼在哪

前两章的题在整份卷子里属于“送分但要接稳”的部分，题型分布大致是这样：

判断和选择之所以占大头，是因为这两类题成本低、覆盖面广，出题人可以用一道题同时考定义、考特征、考边界。下面三节按“概念边界—体系框架—流程角色”的顺序拆。

2.1 项目与日常运作的分界线：四个选项里总有一个是来骗你的

项目的定义要背准：为创造一个唯一的产品或提供唯一的服务而进行的临时性努力。注意“临时性”这三个字，判断题最爱在这动手脚，把“临时性”偷换成“永久性”，答案立刻变错。项目有六个特征：目标性、相关性（限定周期）、临时性、独特性、资源约束性、不确定性。凡是出现“项目可以重复进行”“项目可以无限制使用资源”“项目一旦确定就不会变更”这类表述，一律判错。

项目与日常运作的区别，教材给了四条，其中有一条是假的：

选择题里“项目需要有专业知识的人来完成，而日常运作的完成无需特定专业知识”这一条不是区别，因为日常运作同样需要专业知识，会计、客服、运维都有专业门槛。这道题的杀伤力在于它读起来特别顺，很多人凭语感就选了。另一道常考的是“以下都是日常运作和项目的共同之处，除了”，答案是“都是重复性工作”——由人来做、受限于有限资源、需要规划执行和控制，这三条项目也具备。

提示：判断题里出现“大量变更”的描述时，先分清主语。说日常运作变更多、项目连贯，这就是反了，项目才是变更和不确定性更高的那一方。

还有一道容易翻车的：“过程管理就是对过程进行管理，目的是让过程能被共享、复用并持续改进。”这句听着像废话，但它是对的，属于定义型判断，不要因为“太像废话”就判错。

2.2 五个过程组与十个知识域：问答题怎么答才不丢分

五个过程组是启动、计划、执行、控制、收尾。问答题要求“简述五个过程组及其关系”，很多人只把五个词写出来就交卷，结果只得一半分。完整的答法要分两层：先每个过程组一句话说清它干什么、产出什么，再补一句关系。

关系那一句必须写出来：各过程组通过结果连接，一个过程组的输出是另一个过程组的输入；其中计划、执行、控制是核心管理过程组。这句话是评分点，写了就是三分，不写就是零分。

十个知识领域要能一口气默出来：集成、范围、时间、成本、质量、人力资源、沟通、风险、采购、干系人。选择题最爱的干扰项是“招聘管理”——它听着特别像人力资源管理的兄弟，但知识领域里没有这个东西。另一个高频坑是漏掉“干系人管理”，很多人背到采购就停了，第十个领域直接丢分。

选择题还有一种问法：“以下哪项不包括在项目章程中？”答案是“对项目风险的分析”。项目章程里装的是对项目的确认、对项目经理的授权、项目目标的描述，风险分析是后面规划阶段的事，章程阶段还没做到那么细。

2.3 立项、章程与招投标：甲乙双方的任务清单别记反

立项阶段要办三件事：明确项目目标、明确时间表、明确使用的资源和经费，并且拿到项目发起人的认可。注意是发起人认可，不是项目经理认可，判断题把这两个角色一换，答案就反了。

自造还是购买（make or buy）的决策里，“make”只指自主开发，不含外包，外包属于购买侧。项目建议书是项目初始阶段开发的文档，不是计划阶段的文档，这个概念错位考过不止一次。项目章程是执行组织高层批准的一份书面文件，用来确认项目存在，包含项目确认、项目经理授权、项目目标概述三块内容。

招投标这一块最容易记反的是甲乙双方的任务：

合同签署是双方都做的事，这一点常被忽略。还有一条判断题：“项目招标对于一个项目的开发是必需的，即便项目是内部项目。”这是错的，内部项目根本不需要走招标流程。

人才三角那三个能力也要记牢：技术项目管理、领导力、战略和商务管理。干扰项通常是“测试能力”，它跟项目管理的能力模型没关系。敏捷项目采取的是仆人式管理，这个判断是对的，别被“仆人”两个字带偏成错误项。

3. 生存期模型与需求：从瀑布到敏捷，选型题只有三条判断线

生存期模型的题看着五花八门，其实判断逻辑就三条：需求在项目开始前明不明确、解决方案明不明确、对安全性和性能的要求严不严格。三条一确定，模型基本就锁死了。需求这一章的题则集中在“哪个不是某个过程的组成部分”和“哪个方法的方向反了”。

3.1 五个模型的适用场景：把三条判断线代入就行

先看对照表，考场上直接往里套：

几条判断题要特别留神。“瀑布模型不适合短期项目”是错的，短期项目恰恰适合瀑布，因为沟通成本低、需求容易一次说清。“增量式模型可以避免一次性投资太多带来的风险”是对的。“V 模型适合需求明确、方案明确、对系统性能要求严格的项目”也是对的，瀑布和 V 模型都属于预测型生存期模型。

选择题里最经典的一道是：甲方给了详细准确的需求文档，解决方案也很明确，安全性要求非常严格，选哪个模型？答案是 V 模型。瀑布在这里是最大的干扰项，区别就在“安全性严格”这四个字上。反过来，需求不明确时应该避免选 V 模型，因为 V 模型的前提就是需求锁死。

关于迭代模型，有一道题问“下列说法不正确的是”，答案是“不多次提交”——迭代模型的核心就是多次提交、不断反馈原型，说它不多次提交等于把定义反过来了。

3.2 敏捷：四个价值观、十二条原则、十三个实践

敏捷模型包括四个核心价值，对应十二条敏捷原则，这个数字对要记死，填空题直接考。四个价值观是：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。

选择题会问“下面哪项不是《敏捷宣言》里的内容”，答案是“敏捷开发过程是自适应的过程”。这句话本身是对的，敏捷确实是自适应过程，但它不是宣言里的四条价值观之一，属于“正确但不属于”的陷阱。这类题的解法是先确认题目问的是“对不对”还是“属不属于”。

极限编程有三个层面、十三个实践。它的实践原则包括快速反馈、假设简单、包容变化，不包括“详细设计”——详细设计是传统重量级方法的产物，跟 XP 的轻量理念相反。这道题的坑在于“详细设计”听起来是好事，很多人在潜意识里把它当成正确项。

还有一道必考的判断：Scrum、XP、DevOps 都属于敏捷模型，这是对的；但“敏捷型是预测型和迭代型的混合模型”是错的，敏捷属于适应型，不是预测型的混血。DevOps 是 Development 和 Operations 的组合，填空题直接考这两个英文词。

3.3 需求五过程与结构化方法：数据流图为什么必须是自顶向下

需求管理包括五个过程：需求获取、需求分析、需求规格编写、需求验证、需求变更。选择题的干扰项是“需求更新”，把“变更”换成“更新”，一字之差。

数据流分析方法是一种自顶向下、逐步求精的分析方法。判断题把它写成“自下而上”，答案就是错的。这个点容易记混，因为任务分解那一章确实有自下而上的方法，两章的知识串味了。

数据字典的组成部分是数据项、数据流、数据文件。干扰项有两个层次：一是用“数据库”冒充“数据文件”，二是把“操作指令”塞进来。这两种写法都不对。

结构化方法设计包含数据流图、数据字典、系统流程图，不包括系统用例图——用例图是面向对象那边的需求视图。UML 需求视图包括用例图、状态图、顺序图，甘特图不是需求视图，它是进度图，这个跨界干扰项几乎每年都出现。

还有两个概念要分清：系统响应时间属于非功能性需求，不是功能性需求；需求规格说明书包括系统的运行环境，这句话是对的。判断题里“需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书”是错的，因为标志不止这一条，写成“唯一标志”就过度绝对了。

3.4 用户故事与 UML 视图：敏捷需求为什么不用技术语言

敏捷项目主要采用用户故事描述需求。用户故事的几个特征要记住：它是敏捷需求的描述方式，不是一种数据结构；它不用技术语言来写，因为要写给业务方看；它常常写在卡片上，然后贴到墙上做排期。选择题问“下列关于用户故事描述不正确的是”，答案是“一种数据结构”。

用例图的题一般给一张图让你判断参与者是谁、写出至少三个用例。判断参与者的方法很简单：看谁在系统边界外面主动发起交互。某课务管理系统的图里，参与者是学生用户，用例至少能写出登录、注册、选课三个。这类题不要求你画得多漂亮，只要参与者角色写对、用例动词开头、数量和题目要求对得上，分就拿到了。

注意：需求变更是软件项目的一个突出特点，也是导致项目范围蔓延的直接原因。选择题里“（ ）是软件项目的突出特点，可以导致软件项目的蔓延”，答案就是需求变更，别选“临时性”或“约束性”。

4. WBS、估算与进度：四类计算题的标准解法

这一块是整份卷子里唯一能靠套路拿满分的地方。任务分解和成本估算的题，考法极其固定；进度那一章的概率题，公式也就两个。真正让人栽跟头的是单位换算和“标准差能不能直接相加”这两件事，血泪经验就是：所有计算题先把单位统一到 KLOC 和月，再动笔。

4.1 WBS：树形结构、四种分解方法与五步验证

WBS 的全称是任务分解结构（Work Breakdown Structure），它最底层的可交付成果叫工作包。WBS 的结构是分级的树形结构，不是分层集合，也不是线性结构。每一个具体细目通常指定唯一的编码，编码是 WBS 的身份证。

分解方法有四种：模板参照、类比、自顶向下、自底向上。选哪种取决于你对项目的熟悉程度——如果开发人员对项目比较熟悉、对大局有把握，用自顶向下；如果是一个完全没做过的崭新项目，用自底向上。判断题里“如果开发人员对项目比较熟悉，开发 WBS 时最好采用自底向上方法”是错的，正好反了。自底向上的方向是从特殊到一般，先定义特殊任务再往上组织；自顶向下是从一般到特殊，从大局着手逐步细化。

WBS 的三个作用要背：帮助组织工作、防止遗漏工作、为项目估算提供依据。选择题问“WBS 非常重要，因为下列原因，除了”，答案是“确定团队成员责任”——责任分配是责任矩阵干的事，不是 WBS。

检验 WBS 分解结果的标准有三条：最底层的要素是否是实现项目目标的充分必要条件、最底层元素是否有重复、最底层要素是否有清晰完整的定义。干扰项是“分解的层次不少于 3 层”，教材没有这条硬性要求，层数取决于项目规模。

任务分解的步骤是五步：确认并分解项目的组成要素并编号、确定统一的分解标准、确认分解是否详细到可以作为费用和时间估计的标准、确定可交付成果并编制 WBS 字典、验证分解正确性后建立编号系统。问答题按这五步写，每条前面加序号，比写成一大段更容易踩到分。

判断题还有两条要记：WBS 提供了项目范围基线（对）；不在 WBS 中的任务就不是该项目的工作（对）。敏捷项目里的 Epic 可以继续分解成若干用户故事，这也是对的。

4.2 估算方法对照：什么时候用类比、什么时候用故事点

成本估算的方法多，但每种方法对应一个固定场景，考法就是“项目初期一般用哪种方法”这类定位题。

几个必须记住的细节：功能点的五类组件是外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件；功能点估算与项目使用的语言和技术无关，判断题说“有关”就是错的。故事点估算是一个相对的估算过程，等级序列一般取 1、2、3、5、8、13，所以“注册功能 3 个故事点，成绩录入略多”对应的答案是 5 个点，不是 4 个。

成本分类上，项目人力成本属于直接成本，间接成本是跟具体项目不直接挂钩的那部分，判断题说“间接成本是与一个具体项目相关的成本”是错的。软件产品的主要成本是人的劳动消耗所付出的代价，这句话是对的。

还有一条反复出现的判断题：“在软件项目估算中，估算结果是没有误差的。”这是错的，估算一定有误差，经验对估算非常重要，历史数据也非常重要。选择题问“关于估算说法错误的是”，答案就是“经验对于估算来说不重要”。

4.3 三道成本计算题的完整写法

计算题的手算过程最容易出错，可以把公式写成代码跑一遍核对：

# 三点估算（加权平均）：(乐观 + 4×最可能 + 悲观) / 6 def three_point(optimistic, most_likely, pessimistic): return (optimistic + 4 * most_likely + pessimistic) / 6 # 题1：三位专家分别给出的（乐观, 最可能, 悲观），单位万元 experts = [(2, 7, 12), (4, 6, 8), (2, 6, 10)] each = [three_point(*e) for e in experts] # 先算每位专家自己的三点值 project_cost = sum(each) / len(each) # 再对多位专家取算术平均 print(each, round(project_cost, 2)) # [7.0, 6.0, 6.0] 6.33

这段代码对应的是专家估算法，参数含义：optimistic是最乐观成本，most_likely是最可能成本，pessimistic是最悲观成本。三点公式里最可能值要乘 4，权重最大。三位专家各自算完再取平均，顺序不能反——先平均再套公式，结果会不一样。

# 中等 COCOMO：Effort = a × KLOC^b × F def cocomo(kloc, a, b, effort_adjust=1.0): return a * (kloc ** b) * effort_adjust # 题2：50 KLOC，半嵌入型，只有可靠性为很高级别（1.3），其余属性为 1 effort = cocomo(50, a=3.0, b=1.12, effort_adjust=1.3) # 人月 print(round(effort, 2)) # 311.82 print(round(effort * 2, 2)) # 623.64 万元（2 万元/人月）

参数说明：kloc是千行代码数，不能填 50 以外的单位；a和b由模型档位决定，中等规模半嵌入型取 3.0 和 1.12；effort_adjust是所有属性调整因子的乘积，题目里只有可靠性一项取 1.3，其余正常取 1，所以乘积就是 1.3。最后一步把工作量乘上人月单价，得到费用。

# 题3：代码行经验模型，C 语言按 150 LOC/FP 折算 fp = 85 loc = fp * 150 # 12750 行 kloc = loc / 1000 # 12.75 KLOC，这里最容易写成 1.75 E = 5.2 * kloc ** 0.91 # 工作量，人月 D = 4.1 * kloc ** 0.36 # 持续时间，月 S = 0.54 * E ** 0.6 # 人员需求量，人 DOC = 49 * kloc ** 1.01 # 文档数量，页 print(round(E, 3), round(D, 2), round(S, 3), round(DOC, 3)) # 52.725 10.25 5.829 640.857

这里的坑在单位换算：12750 行等于 12.75 KLOC，不是 1.75 KLOC。教材原文在这一步印错过，抄答案的时候要自己核一遍。四个公式的指数分别是 0.91、0.36、0.6、1.01，S用的是已经算出来的E，不是L，参数传错整道题就废了。

4.4 进度：关键路径、PERT 与概率题的两个公式

关键路径决定了项目在给定资源和成本条件下完成所需的最短时间，它是网络图里最长的那条路径。时间是一种特殊资源，单向、不可重复、不可替代，所以它是项目计划中灵活性最小的因素。判断题说“时间是项目规划中灵活性最小的因素”，对。

网络图有两套画法：ADM（箭线法）里箭线表示活动、节点表示事件；PDM（优先图法）里箭线表示任务之间的逻辑关系、节点表示活动。这两种表示法最容易被互换着考，记住“箭线法箭线是活动，优先图法节点是活动”。

依赖关系分三类：强制性依赖（硬逻辑，比如编码完成才能测试）、软逻辑关系（团队自己定的偏好顺序）、外部依赖关系（项目与非项目活动之间的依赖）。选择题问“软件编码完成之后我才可以对它进行软件测试，这说明了哪种依赖关系”，答案是强制性依赖关系。

任务之间的四种关系是结束-开始、开始-开始、结束-结束、开始-开始之外还有开始-结束，题目里出现“结束-开始-结束”这种三段的写法就是错的。搭接时间上，lag 会延长项目进度，lead 会缩短。

时间压缩有两种方法：应急法和平行作业法。应急法必须选关键路径上的活动来压缩，判断题说“不一定要在关键路径上选择活动”是错的。快速跟进指的是采用并行执行任务来加速进展，跟赶工不是一回事。

PERT 的公式只有一个：历时 =（乐观 + 4×最可能 + 悲观）/ 6，标准差 =（悲观 − 乐观）/ 6。概率题靠的是正态分布的经验值：落在正负一个标准差内约 68.3%，两个标准差约 95.5%，三个标准差约 99.7%。

import math def pert(o, m, p): e = (o + 4 * m + p) / 6 delta = (p - o) / 6 # 单个活动的标准差 return e, delta # 单活动题：乐观 6 天，最可能 12 天，悲观 24 天 e, d = pert(6, 12, 24) print(e, d) # 13.0 3.0 → [10, 16] 概率 68.3% # 串联任务题：三条任务依次串起来，先算各自 E 和方差 tasks = [(2, 3, 6), (4, 6, 8), (3, 4, 6)] total, var = 0.0, 0.0 for o, m, p in tasks: e, d = pert(o, m, p) total += e var += d ** 2 # 方差可以相加，标准差不能直接相加 sigma = math.sqrt(var) print(round(total, 2), round(sigma, 2), round(total + sigma, 2)) # 13.5 1.07 14.57

关键在最后两行：串联任务的总方差是各活动方差之和，总标准差要开根号，直接把三个标准差加起来是典型错误。算出 14.57 之后，它正好等于 E + δ，所以概率是 50% 加上 68.3% 的一半，约 84.15%。

提示：估算活动时间存在很大不确定性时，用 PERT 而不是 CPM。CPM 是单点估算，PERT 才处理三值区间。

最后两个图表概念：甘特图能直观显示任务的工期、起止时间和资源信息；燃尽图用来表示敏捷项目的进度和剩余任务量。里程碑图只标关键节点，不显示任务细节。选择题问“哪一项可以表示敏捷项目的进度并且能表示出剩余任务”，答案就是燃尽图。

5. 易错点：质量、配置、沟通、风险四域的五类失分点

后面这几章的题有个共同特点——概念都认识，一做题就错。原因是这些领域里成对出现的概念太多，质量保证与质量控制、基线与版本、回避与转移、职能型与项目型，出题人只要把两边的定义对调一下，就能造出一道看起来毫无破绽的错题。下面按领域拆，最后单独收五条最高频的失分点。

5.1 质量：QA 和 QC 谁管过程、谁管产品

软件质量是软件满足明确说明或者隐含的需求的程度，这句话要背原话，判断题会把它拆成两半分别考。质量管理的三个过程是质量计划、质量保证、质量控制，没有“质量优化”这个东西，选择题的干扰项就在这儿。

质量成本包括预防成本和缺陷成本。质量计划的方法有质量成本分析、因果分析图、基准对照，不包括抽样分析——抽样统计是质量控制阶段用来降低控制成本的手段，不是计划方法。这道题的坑在于抽样听起来像计划工作，其实它是执行后的检查手段。

质量保证和质量控制的区别必须能说清：

|

本文还有配套的精品资源，点击获取