企业官网建设流程全解析

简介：《软件项目管理案例教程（第四版）》课后答案文档面向高校软件工程、项目管理课程学生及备考人员，用于对照教材章节习题，快速核对填空、判断、选择与问答题答案，也可供任课教师备课参考。压缩包内共1个docx文件，约1.1MB，按章节组织题目与解答，便于检索和打印复习。内容围绕项目管理五个过程组、项目特征、敏捷开发四价值观与十二原则、PMBOK十个知识领域展开，并涉及项目与日常运作的区别、项目立项、项目章程、甲方乙方招投标、自制或购买决策、瀑布与增量模型、DevOps及Gantt图、PERT图等工具技术，答案与教材知识点对应，可帮助读者梳理概念边界、复盘易错判断和选择题。已有5432人学习，适合课程复习、考前查漏补缺与作业核对时使用。

1. 搬家、装修和一次性的活儿：软件项目管理到底在管什么

搬家这件事，一辈子可能就干那么几次，每次的东西不一样、天气不一样、帮忙的人也不一样，没人会给你一份“搬家标准作业手册”照着做。软件项目也是这个味道：目标明确、只做一次、资源有限、中途总出岔子。搞懂软件项目管理，本质上是搞懂怎么把这种“一次性、没法重来”的活儿，拆成能安排、能追踪、能收尾的步骤，而不是凭感觉硬扛。很多人翻课后答案时只记 ABCD，其实真正该记的是判断依据——为什么搬家算项目、为什么每天扫地不算。这套依据一通，五大过程组、生存期模型、WBS、关键路径这些名词就不再是散落的考点，而是一条线上的珠子。

2. 五个过程组：一个项目从生到死的呼吸节奏

启动、计划、执行、控制、收尾，这五个词背起来毫不费力，但被追问一句“为什么是这五个、少一个行不行”，大部分人立刻卡壳。它们不是编教材的人拍脑袋定的顺序，而是对应任何一件“没做过的事”都必须回答的五个问题：要不要干、怎么干、干起来、有没有跑偏、怎么算完。把这五个问题答完，项目才从一个念头变成一件能交付的东西。

2.1 启动和计划：先把手里的活儿钉在纸上

启动过程组要干的事只有一句：确定一个项目或一个阶段可以开始了，并且正式授权它。落到纸面上就是项目章程——由项目执行组织的高层批准、书面确认项目存在的文件，里面写着对项目的确认、对项目经理的授权、项目目标的概述。

这里有个常被记反的点：项目章程通常不包括对项目风险的分析。很多人直觉上觉得“立项当然要评估风险”，但章程解决的是“这个项目算不算数、谁说了算”，风险分析属于后面的活儿。把这两件事分开，后面看变更审批、看谁签字，就不会乱。

立项阶段还有三个必须写清楚的东西：目标、时间表、使用的资源和经费，并且要拿到项目发起人的认可。发起人和项目经理是两个角色——项目经理是被授权的人，发起人是给出授权的人。这个区分在招投标、合同、变更审批里会反复出现，混了一次，后面就到处别扭。

立项之后紧接着一个很现实的决策：自造还是购买。哪些部分自己研发、哪些采购、哪些外包，这一步定了，成本结构基本就定了。判断依据通常不是拍脑袋，而是比较两条成本线的交点。有一道经典算例：自制一次性投入 30000 元、每月维护 3500 元；购买 18000 元、每月维护 4200 元。两个方案的前期差价 12000 元，除以每月的维护差额 700 元，得 17.14 个月——用不到 17 个月就买，超过 17 个月就自己做。这种“交点思维”比背一个结论有用得多，因为换个数字你照样能算。

计划过程组要干的，是把目标翻译成一份实际可行的工作计划，并且把它固定成基准。基准这个词听着抽象，其实就是一把尺子：后面所有“进度慢了”“钱花超了”的判断，都是拿实际值去量这把尺子。没有基准，控制过程组根本无从谈起，因为它连“偏没偏”都没法回答。

2.2 执行、控制、收尾：一边跑，一边修方向盘

执行过程组最朴素：按照已经定下的基准计划，协调人力和其他资源，把计划或相关子计划做出来。关键词是“协调”，因为项目里最常见的困境不是没人干活，而是三个人同时等一个人，谁都不好意思催。

控制过程组最容易被误解。它不是盯着大家别偷懒，而是持续拿实际进展和基准比对，发现偏差就采取修正措施。这里面有一个听上去拗口、实际上极其重要的动作——集成变更控制。为什么强调“集成”？因为一个变更从来不孤立：需求加一个字段，进度要挪、成本要加、测试用例要补、文档要改。只批了需求、没同步改另外三样，就是最常见的翻车现场，而且往往要到上线前一天才爆。

收尾过程组也不是“散伙”。它要做的是取得项目或阶段的正式认可，然后有序地结束：向客户交付产品、发布结束报告、更新组织过程资产、释放资源。组织过程资产这个词有点绕，说白了就是“下次还能接着用的东西”——模板、检查单、踩坑记录。项目是一次性的，但这批东西可以复用，这也是为什么同一个团队做第二个同类项目，总比新组建的团队少走弯路。

五个过程组之间的关系不是排队买饭，而是串联加循环。一个过程组的输出是另一个过程组的输入，其中计划、执行、控制这三个构成核心管理过程组，启动和收尾分列两头。真实项目里，控制过程组发现偏差之后，往往要倒回去改计划，于是又走一遍计划—执行—控制。所以一周之内把这套循环走两遍，完全正常。

2.3 为什么偏偏是五个：过程组不是阶段

初学者最容易混的一对概念，就是“过程组”和“阶段”。它们名字都像时间切片，其实完全不是一回事。阶段是按时间划分的：需求阶段、设计阶段、开发阶段、测试阶段，一个接一个往前推。过程组是按“干什么性质的事”划分的：启动、计划、执行、控制、收尾，它们可以在任何一个阶段内部循环。

打个比方，装修一套房子，水电阶段、泥瓦阶段、木工阶段是“阶段”；而每个阶段里你都要先想清楚做什么（计划）、动手做（执行）、去现场看看有没有歪（控制），最后验收这一项（收尾）。你不会因为已经进入木工阶段，就不再需要“计划”和“控制”了。

理解这一点，很多课后题就自动通了。比如“一个项目只有一个启动过程组和一个收尾过程组”——不完全对，因为每个阶段都可以有自己的启动和收尾。再比如“控制过程组就是管人”——不对，它管的是偏差和变更，人归组织和沟通那部分管。

还有一个常见的误解：以为过程组做得越全越好。实际情况恰恰相反，过程组的裁剪是项目管理里最见功力的部分。三个人两周做一个小工具，非要写完整的项目章程、开三次变更评审会，那不叫规范，那叫自我消耗。规范的价值在于降低“一次性的事做砸”的概率，当这件事本身很小、砸了也不疼的时候，全套流程就是纯成本。判断标准始终是那一条：犯错代价有多大。

最后补一句关于输入输出的理解。五个过程组靠结果连起来，一个过程组的输出就是另一个过程组的输入，这句话听起来像套话，但它解释了为什么“计划改了就全乱”。计划是执行的输入，执行是控制的输入，控制又会反过来产生新的计划输入。链条上任何一环被悄悄改动而没通知下游，下游所有判断就都建立在假数据上了。

3. 生存期模型：瀑布、V、原型、敏捷各自适合什么项目

生存期模型解决的是一个很具体的问题：这个项目从开始到结束，走一条什么样的路线。路线选错了，后面再努力也是逆风骑车。业内常把它们先劈成两半：预测型和适应型。前者假设“想清楚了再动手”，后者假设“边做边想清楚”。

3.1 预测型与适应型：一条光谱，不是两个阵营

预测型模型的前提是：需求在项目开始前就比较明确，解决方案也比较明确，变更不多或者变更代价很大。它的好处是计划性强、责任清晰、便于按合同验收；代价是一旦需求判断错了，返工成本极高。瀑布模型、V 模型都属于这一侧。

适应型模型的前提正相反：需求会变，而且变化本身是常态，与其赌一次性想清楚，不如把大目标切成小段，每段都交付一点能用的东西，靠反馈来修正方向。敏捷属于这一侧，它的典型特征是短周期迭代、持续反馈、自适应调整。

把这两类理解成一条光谱而不是两个阵营，会少很多争论。真实项目常常落在中间：核心账务模块用预测型，前端交互用适应型；合同里写死的部分按瀑布走，探索性的部分按迭代走。把几种模型组合成一种混合模型，让项目沿着最有效的路径推进，这本身就是一种正经做法，不是“不纯粹”。

3.2 瀑布和 V 模型：需求越确定，越敢按顺序走

瀑布模型的定义很好记：所有活动严格按照顺序执行，一个阶段的输出是下一个阶段的输入。它的适用条件也很清楚——需求明确、功能完整、没有重大变化，同时团队对这套流程比较熟悉。顺带纠正一个常见错觉：瀑布并不排斥短期项目，短期项目反而可以用瀑布，因为周期短、变化机会少。

V 模型长得像字母 V，左边一路下降是需求、设计，右边一路上升是各种测试，每个开发阶段都对应一个测试阶段。它适合的场景非常具体：需求在项目开始前就很明确、解决方案也很明确，而且对系统的安全性、性能要求严格——飞行控制系统、财务系统是教材里最常举的例子。为什么这类项目偏爱 V 模型？因为它的验证是“一对一咬合”的，需求阶段写完的验收标准，在验收测试阶段必须逐条对上，中间不留模糊地带。

这两类模型共有的软肋是：需求本身错了，越严谨越糟。所以当需求在项目开始前根本说不清的时候，硬上 V 模型是最危险的选择之一。

3.3 敏捷与迭代：把大目标切成能交付的小块

敏捷不是一套工具，而是一组价值观加一组实践。四个核心价值分别是：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。它们对应十二条原则。这里有个教材里反复设坑的点——“敏捷开发过程是自适应的过程”这句话是对的，但它不是《敏捷宣言》里的内容，而是对敏捷性质的描述。判断“下列哪项不是宣言内容”时，就靠这个区分。

敏捷家族里常见的成员包括 Scrum、XP、DevOps 等。极限编程（XP）从三个层面提供了十三个敏捷实践，它的实践原则里包含快速反馈、假设简单、包容变化，但不包含“详细设计”——这一点经常被拿来出选择题。DevOps 顾名思义，是 Development 和 Operations 的组合，把开发与运维之间的墙拆掉，让交付和反馈的循环更短。

需求怎么描述？敏捷项目主要用用户故事。用户故事写在卡片上，贴在墙上，用业务语言而不是技术语言描述“谁、想做什么、为什么”，它描述的是一种需求，不是一种数据结构。这一点非常容易混：一看到“故事”两个字就往数据结构上想，就偏了。

计划怎么排？敏捷采取远粗近细的模式：发布计划相当于远期计划，迭代计划相当于近期计划。远期的颗粒度粗，因为那时候信息少，写细了也是假的；近期的颗粒度细，因为马上要动手。进度怎么看？看燃尽图——它能表示剩余任务量，和甘特图那种“谁在什么时候干什么”的表达完全不是一回事。

迭代模型还有几个特征值得记住：不断反馈原型、可以加快开发速度、适合需求变化大的项目、需要多次提交。相对地，增量式模型的好处是可以避免一次性投入太多带来的风险。至于“一次性提交”这种说法，恰恰是迭代模型的反面。

4. 常见误区：五组最容易记混的概念

教材里的判断题之所以难，不是因为知识点深，而是因为选项往往长得很像。下面五组是出错率最高的，每一组都按“易混在哪、为什么会混、怎么区分”说清楚。

4.1 项目与日常运作：一次性的，还是重复性的

易混点：两者都由人来做、都受资源限制、都需要规划执行和控制，看着几乎一样。

为什么会混：共同点太多，而区别只有一条——重复性。很多人抓住“有目标”这一点就往下判断，结果把日常运作也算成项目。

怎么区分：问一句“这件事做完之后，还会不会原样再做一遍”。搬家、野餐活动、集体婚礼、开发一个操作系统，都是一次性的，属于项目；每天的卫生保洁、社区保安、上课，是重复性的，属于日常运作。项目有明确的起点和终点，日常运作是持续进行的。另外，项目可以变更，日常运作追求稳定连贯；项目对资源成本有约束，但不会“无限制使用资源”。至于“需要有专业知识的人来完成”这条，恰恰不是项目与日常运作的区别，因为两边都需要。

4.2 质量保证与质量控制：一个管过程，一个管产品

易混点：都叫“质量”，都要花钱，都跟缺陷有关。

为什么会混：中文里“保证”和“控制”都像“把质量搞好”，语感上分不出方向。而且两者的活动经常在同一个项目里交错发生。

怎么区分：质量保证针对的是过程，主要活动是项目执行过程审计和项目产品审计，它本身并不能直接提高产品质量，而是通过评价项目整体绩效、建立对质量的信任、提供可视化报告来间接起作用，一般由质量保证部门的人实施。质量控制针对的是产品，检查具体可交付成果是否符合质量标准，找到不符的原因并消除，它直接提高产品质量，一般由开发人员实施。一句话记：质量保证是管理手段，问“我们做事的方式对不对”；质量控制是技术手段，问“这个东西合不合格”。

4.3 里程碑与基线：一个是被标记的时间点，一个是被冻住的版本

易混点：都和“阶段结束”有关，都出现在进度讨论里。

为什么会混：基线常常在里程碑那一刻形成，两件事同时发生，于是被当成同一件事。

怎么区分：里程碑是时间轴上的一个标记，本身不产生文件；基线是一组配置项通过审核后形成的稳定版本，标志开发过程中一个阶段的结束。基线产品不是不能改，而是必须走基线变更控制流程，经过软件配置控制委员会授权才能改。所以“基线不可变化”是错的，“基线修改不需要走正式程序”也是错的。记住一句话：基线是“可以改，但要按规矩改”。

4.4 估算与预算：一个是猜，一个是分

易混点：都跟钱和时间有关，都用数字表达。

为什么会混：实际做项目时，估完常常直接当成预算用，两个动作粘在一起。

怎么区分：估算是在信息不足的情况下给出的一个区间判断，它天然有误差，所以才有三点估算法——最乐观、最可能、最悲观三个值加权，目的就是把不确定性显性化。预算则是把估算结果按时间段、按工作单元分配下去，形成成本基线，用于后续的跟踪和考核。估算可以错，预算必须能对账。还有一条常考：经验对估算很重要，历史数据也很重要，但估算结果不可能没有误差，也别太迷信数学模型。

4.5 回避风险与转移风险：一个是不干，一个是让别人扛

易混点：两者都能让“自己”免受损失，听起来都是把风险弄没了。

为什么会混：结果上看损失确实没落到自己头上，于是被归成一类。

怎么区分：回避风险是主动放弃或拒绝使用导致风险的方案，风险本身消失了，机会也一起消失；转移风险是把风险的后果连同应对责任转给第三方，风险还在，只是换了承担者——买保险是典型的转移，不是回避。另外，对团队做技术培训以降低新技术带来的失败概率，属于损失控制，不是回避也不是转移。这三个词经常被放在同一道选择题里，靠“风险还在不在、由谁承担”就能分辨。

5. 三张看不见的图纸：WBS、关键路径、配置管理

项目管理里最值钱的东西往往不是文档，而是三张看不见的图：把工作切开的图、把时间串起来的图、把版本管住的图。它们分别回答三个问题——做什么、多久做完、改了以后怎么找回来。

5.1 WBS：把大象切成一个人能吃完的块

WBS 的全称是任务分解结构，做的事很朴素：把一个项目分解成更多的工作细目或子项目，让项目变得更小、更易管理、更易操作。它最底层的可交付成果叫工作包，一个工作包应当由唯一的责任人负责，也必须小到能分配给一个人完成。

WBS 为什么重要？三条：帮助组织工作、防止遗漏、为估算提供依据。但它不负责“确定团队成员责任”，那是责任分配矩阵的活儿。这个区分在选择题里出现频率极高。

分解方法有四种：模板参照、类比、自上而下、自下而上。自上而下是从一般到特殊，从项目大局着手，逐步分解子细目；自下而上是从特殊到一般，先定义一些具体任务，再往上组织成更高层。选哪种不看哪个高级，看情况：项目是全新的、没做过的，适合自下而上；团队对项目比较熟悉、对大局有把握，适合自上而下。教材里那句“熟悉项目时最好用自底向上”是错的，就是因为把方向搞反了。

WBS 的结构是一棵分级的树，不是分层集合，也不是线性结构。每个细目通常指定唯一的编码，编码是后面做成本归集和进度跟踪的锚点。判断一个 WBS 分解得合不合格，看四条：最底层要素是不是实现项目目标的充分必要条件、最底层要素之间有没有重复、每个要素有没有清晰完整的定义、能不能作为费用和时间估算的标准。注意，“分解层次不少于三层”不是检验标准——层次多少取决于项目大小，硬凑层数只会切出没有意义的工作包。

WBS 还有一个隐性作用：它是范围基线。不在 WBS 里的任务，就不是这个项目的工作。这句话听着霸道，但它是对付范围蔓延的唯一有效武器。需求方临时加一句“顺便再做个小功能”，你可以指着那棵树说：这个不在范围里，要做得走变更。敏捷项目里也有对应物：一个 Epic 可以继续分解成若干用户故事，颗粒度从“一大块愿望”落到“一个迭代能做完”。

5.2 关键路径：决定最短工期的，是最长的那条链

关键路径是项目网络图里最长的一条路径，它决定了在给定资源和资金条件下，项目完成所需的最短时间。这个说法第一次听会觉得别扭：最长的路径怎么反而决定最短时间？因为项目要等所有路径都走完才算结束，最长的那条就是瓶颈，其他路径都有富余时间可以等。

围绕这条路径，有几个必须记牢的公式：最早完成等于最早开始加历时，最晚开始等于最晚完成减历时，总浮动等于最晚开始减最早开始，也等于最晚完成减最早完成。而“最早完成等于最早开始加延迟（lag）”是错的，延迟是加在最晚时间那一侧的约束。

浮动时间这个概念，通俗地说就是“在不耽误总工期的前提下，这个活动最多能拖多久”。它是进度灵活性的度量，但注意，浮动不等于“不增加成本的前提下可以拖”——两码事。

活动之间的依赖关系分几类：强制性依赖（硬逻辑，比如编码完成才能测试）、软逻辑（团队自己定的偏好顺序）、外部依赖（项目与非项目活动之间的关系，不叫强制性依赖）。时间压缩有两条路：应急法（赶工，加资源）和平行作业法（快速跟进，把原本串行的活动改成并行）。赶工不是随便挑活动压，得挑关键路径上的；压缩非关键路径上的活动，工期一天都不会少。而且关键路径在项目进行中会变，资源一挪、工期一拖，瓶颈可能就换到另一条链上去了。

还有一个绕不开的工具是三点估算，即计划评审技术里的加权平均。它把乐观值、最可能值、悲观值按 1:4:1 加权，同时用悲观值与乐观值之差除以 6 得到标准差，用来衡量不确定性大小。标准差越大，说明这个活动的估算越不靠谱。

# 三点估算：O 乐观值、M 最可能值、P 悲观值 def pert(o, m, p): expected = (o + 4 * m + p) / 6 # 期望历时，中间值权重最高 sigma = (p - o) / 6 # 标准差，反映估算的离散程度 return expected, sigma e, s = pert(2, 3, 6) # 某活动：最快 2 天、最可能 3 天、最慢 6 天 print(round(e, 2), round(s, 2)) # 输出 3.33 0.67，即约 3.3 天，波动约 0.7 天

三个参数的含义很直白：o 是顺利情况下的下限，p 是最糟情况下的上限，m 是凭经验最可能落到的那一点。中间值乘 4，是因为它最接近现实。算出期望和标准差之后，就能估算概率：落在期望加减一个标准差区间的概率约 68.3%，加减两个约 95.5%，加减三个约 99.7%。所以问“项目在某个日期前完成的概率”，做法是把各活动的期望相加、方差相加，再换算成区间，最后取一半加一半。这套算法看着唬人，其实就是把“大概”“差不多”翻译成能对照的数。

5.3 配置管理与基线：给文件准备的后悔药

配置管理管的是“变化中的产物”。它的核心功能是完整性和可跟踪性，也就是保证每个配置项都找得到、每个改动都追得回。它不能保证软件的正确性——这一点常被误解，配置管理能管住版本，管不住逻辑对不对。

基本过程可以记成六步：配置项标识与跟踪、配置管理环境建立、基线变更管理、配置管理审计、配置状态统计、配置管理计划。其中基线变更控制的步骤是：提出变更请求、评估变更、批准或拒绝、实施变更。审批权在软件配置控制委员会手里，它的职责是评估变更、批准变更申请、在生存期内规范变更流程、对变更进行反馈、与项目管理层沟通——注意，它不负责“提出变更申请”，提申请的是需求方或开发人员。

常见的配置管理事故其实很具体：找不到某个文件的历史版本、开发人员未经授权改代码或文档、多人协同或异地开发时版本混乱导致整个项目失控。这些问题和“甲方乙方在资金调配上意见不一致”完全是两回事，后者是合同与商务问题，不归配置管理管。

哪些东西算配置项？范围比想象中广：项目计划、需求分析结果、需求规格说明书、设计规格说明书、源代码清单、测试计划、测试用例与实验结果、可执行程序、用户手册、维护文档，都在里面。而且每个项目的配置项集合是不一样的，不存在“所有项目配置项相同”这回事。

5.4 组织结构与沟通：人一多，话就贵了

组织结构有三种基本类型：职能型、项目型、矩阵型。职能型能充分发挥部门资源优势，适合主要由一个部门完成、或者技术比较成熟的项目；项目型的项目经理对资源掌控力最强，但成员往往缺乏归属感；矩阵型在两者之间取平衡，适合涉及多个领域和较多特性的项目。

沟通渠道的数量是 n(n-1)/2，这个公式解释了一个反直觉的现象：人多一点，沟通成本不是线性增长，而是平方级增长。5 个人是 10 条渠道，加到 8 个人就是 28 条，涨了 2.8 倍。20 个人的团队，渠道多达 190 条。所以“应尽量多建立沟通渠道”是错的，渠道越多，信息损耗越大。

沟通方式可以按好几组来分：书面与口头、语言与非语言、正式与非正式、单向与双向、网络沟通。原则是及时、准确、完整、可理解。实操上有一条血泪经验：紧急的信息走口头，重要的信息走书面；特别重要的内容不能只发一封邮件，还要电话提醒、要回执，必要时开会当面讲。在 IT 项目里，沟通失败往往是最大的威胁，项目经理花在沟通上的时间通常占到 75% 到 90%，这个比例不是夸张，是常态。

敏捷团队在这方面反而回到了最朴素的状态：一般 3 到 9 人，集中在一个场地开发，能围坐一桌开会。人少、坐得近，沟通渠道自然就少，这不是偷懒，是在主动压缩沟通成本。

6. 什么时候该上这套方法，什么时候别硬套

学完这一整套，最容易犯的错是“手里有锤子，看什么都像钉子”。三个人两周做一个小工具，非要写项目章程、开三次变更评审会、建配置控制委员会，那不叫规范，那叫自我消耗。

判断标准其实只有三条：这件事是不是一次性的、做砸了代价多大、有没有外部的人等着验收。三条都“是”，就该上方法；三条都“否”，就该轻装。

举个具体例子。某实验室要做一个活动报名页面，参与者是内部同学，用两周。这种活儿上全套项目管理是浪费，但完全不管也会翻车。合理的做法是：花二十分钟在纸上画一棵两层的 WBS，把“报名、审核、通知、导出名单”四块列出来；指定一个人做验收；定一个硬日期；然后就开始写。不需要基线，不需要配置控制委员会，但需要一条——任何加需求的人，都得先说清楚“砍掉原来哪一块”。没有这条，两周变四周是必然的。

反过来，什么时候千万别硬套？需求还在剧烈变化、外部接口又全都写死、根本无法分批交付的时候，硬上敏捷迭代只会得到一堆不能用的半成品；而对一个谁都没做过的全新项目，硬要自上而下拍一棵 WBS，拍出来的多半是想象。那时候自下而上先摸几块石头，反而更靠谱。

我自己的教训来自一次“觉得没必要”的经历：一个小功能，三个人，估了五天，谁都没写验收标准。第四天需求方说“其实我想要的是另一个东西”，那一刻没有任何文件能证明我们当初对齐过什么，只能全部重做。从那以后我每接一个活儿，都会先在纸上写三行——谁验收、什么时候交、做砸了最坏是什么后果。写完这三行，再决定要不要上 WBS、要不要建基线、要不要拉变更流程。这三行只花两分钟，但它是所有方法论的开关。

希望帮到你。

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