第6章 · 播客 第1集
开发方法 · 软件生命周期与瀑布模型
🎙️ 本集播客：第1集：从 GB8566-88 的八阶段生命周期开始，逐段讲清每个阶段在干什么，再进入瀑布模型——为什么它是「面向文档」的、V 模型里需求分析对应哪个测试、以及那四条连 V 模型都躲不掉的缺点，全是选择题的直接取材点。 语音由微软 Edge 神经网络语音预生成（女声·晓伊，男声·云希）。点击下方任意对话可直接从该句开始播，当前句朗读时下一句已预先加载，无缝衔接。
明
阿明
师姐，第五章总算考完了，开发方法这章我粗翻了一下，全是模型：瀑布、螺旋、增量、XP、Scrum……这章是不是就是背模型？
雅
小雅
背是一定的，但这章的问题恰恰在于：模型太多，长得还像。考试从来不问「瀑布模型是什么」，而是把五个模型的优缺点、适用场景打乱了混在选项里让你挑。所以学这章的办法是——每个模型抓一个「身份证」，一句话认出它。这集先打地基：软件生命周期和瀑布家族。
明
阿明
生命周期我知道，就是软件从生到死嘛。
雅
小雅
对，原文的表述是：软件生命周期就是指软件自开始构思与研发到不再使用而消亡的过程。但考点不是这句定义，而是阶段划分。有关软件生命周期的阶段划分，不同的标准有不同的规定，考试考的是国标 GB8566-88，全名《软件工程国家标准——计算机软件开发规范》，它将软件生命周期划分为 8 个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。
明
阿明
八个。这题我见过，选项里放了个 7 个，是不是故意把某个阶段藏起来？
雅
小雅
对，最常见的就是拿「详细设计」或者「集成测试」开刀——因为有人觉得设计算一个大阶段、测试算一个大阶段，一合并就剩七个了。国标口径是设计的两段分开、测试的两段也分开。8 这个数以及八个名字，必须一秒反应。
明
阿明
那这八个阶段各自在干嘛？我每次看都糊。
雅
小雅
一个一个过，每个阶段记一个「产出」。第一，可行性研究与计划：在决定是否开发软件之前先做可行性研究，确定开发此软件的必要性，并根据结果初步确定软件的目标、范围、风险、开发成本等，制定初步的软件开发计划。注意产出：如果确定有研发的必要，将产生《可行性研究报告》和《软件开发计划》两份东西，然后才进入需求分析。
雅
小雅
第二，需求分析：经过可行性研究初步确定了目标和范围之后，对软件需求进行细致分析，确定软件要做成什么样。原文给它的定性很重——需求分析是软件开发过程中极其重要的一环，如果出现重大偏差，软件开发必然偏离正确的道路，越走越远；错误到后期才被发现，修正的代价非常大。这句话是后面理解所有模型的钥匙，先记着。
明
阿明
为什么钥匙？
雅
小雅
因为后面讲的瀑布模型的缺点、螺旋模型的动机、敏捷的兴起，全部围着「需求会错、需求会变」这句话转。现在先往下走。第三，概要设计：确定整个软件的技术蓝图，负责将需求分析的结果转化为技术层面的设计方案，需要确定系统架构、各子系统间的关系、接口规约、数据库模型、编码规范等内容，它的结果将作为程序员的工作指南。第四，详细设计：完成编码前最后的设计，在概要设计基础上进行细化，比如类设计。
明
阿明
等等，详细设计有个坑吧？我好像记得它不是必需的。
雅
小雅
记性不错。详细设计不是开发过程中必需的阶段，在一些规模较小、结构简单的系统中，详细设计往往被省略；同样，在某一次软件开发中，可能只会对部分关键模块进行详细设计。判断题就爱问「每个系统都必须做详细设计」——错。第五，实现：实现过程包括编码和单元测试。单元测试指的是对刚刚编写出的一个小的程序单元进行测试，比如某一个过程、方法或函数；因为单元测试的对象是小的程序单元而不是完整的程序，往往需要编写一些测试程序来进行测试。
雅
小雅
第六，集成测试，又称为组装测试。通过单元测试的程序并不意味着没有缺陷，当程序单元被集成到一起交互时，往往会出现单元测试中不能发现的问题。同单元测试不同，集成测试必须经过精心的组织，指定集成测试计划，确定如何集成、按什么顺序测试、用什么测试数据。第七，确认测试：完成集成测试后，软件之间接口方面的错误已经排除，这时需要验证软件是否同需求一致、是否达到预期目标。
明
阿明
确认测试的「确认」是对着需求确认？
雅
小雅
对，一句话记：集成测试排接口的错，确认测试对需求验货。最后第八，使用和维护：即使通过了单元测试、集成测试和确认测试，也不可能发现软件系统中的全部缺陷，软件系统的需求也会根据业务的发展变化而变化，因此必须不断对软件进行维护，修正缺陷、修改不适应的功能或增加新功能。维护贯穿整个使用过程；当使用和维护阶段结束，软件系统自然消亡，生命周期结束。
明
阿明
八个阶段齐了：可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。可这跟开发模型是什么关系？
雅
小雅
生命周期说的是「分几步走」，开发模型说的是「这些步怎么走、按什么节奏走」。原文交代了背景：在计算机刚刚诞生的年代，人们对软件的认知仅仅停留在程序的层面上，所谓软件开发就是天才们写的一些只有计算机才能理解的二进制序列；但随着软件复杂度不断提高，进入大规模软件开发的时代，人们发现必须遵循一定的开发方法才能取得成功，于是把这些模式化的开发方法称为开发模型。第一个登场的，就是瀑布模型。
明
阿明
瀑布，顾名思义，水只会往下流。
雅
小雅
它的核心思想用原文的类比最好记：软件开发是一个阶段化的精确的过程，就像要制造一艘航空母舰——首先需要知道航空母舰的参数，长宽高、排水量、航速；在这些参数的基础上进行总体设计和详细设计，只有设计得一清二楚的图纸才能交付施工，否则造出的零件肯定拼装不到一起；制造完毕后把零件一个一个拼装成发动机、船舱等部分，并检查这些部分是否符合设计标准，这就是集成测试；最后把各部分组合在一起，造出完整的航母。软件同理，要经过需求分析、总体设计、详细设计、编码、调试、集成测试和系统测试，才能被准确地实现。
明
阿明
每个阶段之间是可以回头的吧？我记得图里有向上的箭头。
雅
小雅
有，但那是反馈线，不是常规路线。每一阶段都有回到前一阶段的反馈线，指的是在软件开发中当在后续阶段发现缺陷的时候，可以把这个缺陷反馈到上一阶段进行修正。注意措辞：是「发现缺陷时回头修」，不是「随时想改就改」——瀑布的主体仍然是自上而下走完。
雅
小雅
然后是瀑布模型最重要的一个标签，考试直接考：瀑布模型的一个重要特点是软件开发的阶段划分是明确的，一个阶段到下一个阶段有明显的界线；在每个阶段结束后，都会有固定的文档或源程序流入下一阶段——需求分析阶段结束后，需要有明确描述软件需求的文档；总体设计结束后，有描述软件总体结构的文档；详细设计结束后，有可以用来编码的详细设计文档；编码结束后，代码本身被作为文档流到下一个阶段。因此也称瀑布模型是面向文档的软件开发模型。
明
阿明
所以「瀑布模型是面向文档的」，这是褒义标签不是骂它。那它什么时候能用？
雅
小雅
原文一句话：当软件需求明确、稳定时，可以采用瀑布模型按部就班地开发软件；当软件需求不明确或变动剧烈时，瀑布模型中往往要到测试阶段才会暴露出需求的缺陷，造成后期修改代价太大，难以控制开发的风险。这道题的标准问法是「瀑布模型的核心特点和最大缺陷分别是」，选项四个组合：面向文档驱动、难以适应需求变化，这是对的；其他几个干扰项说面向测试驱动、面向风险驱动、面向用户驱动——记住，面向测试的是 V 模型侧重的事、面向风险的是螺旋模型、面向用户参与是螺旋的优点，都不是瀑布。瀑布就是文档驱动加难适应变化。
明
阿明
把别的模型的标签错配给瀑布，这招阴。V 模型呢，它跟瀑布什么关系？
雅
小雅
瀑布 V 模型是瀑布模型的一种变体。背景是：随着应用，人们发现缺陷无法避免，任何一个阶段都会在软件中引入缺陷，而最后的测试也不能保证完全没有缺陷，只能争取在交付前发现更多；测试的质量直接影响到软件的质量。于是人们对瀑布模型进行了小小的更改，提出更强调测试的瀑布 V 模型。形态上，整个瀑布模型在编码与调试阶段转了个弯，形成一个对称的 V 字，左边往下走是开发，右边往上走是测试。
明
阿明
这个 V 字最考的就是谁对谁吧？我老记反。
雅
小雅
三组对应，这是本章的高频题。瀑布 V 模型在进行完需求分析后就进入总体设计阶段，但除总体设计外，需求分析还有一条虚线指向系统测试——这指的是，需求分析的结果将作为系统测试的准则，需求分析阶段也将产生同软件需求一致的系统测试；软件产品是否符合最初的需求，将在系统测试阶段得到验证。以此类推，总体设计对应了集成测试，详细设计对应了单元测试。
明
阿明
我背个口诀行不行：需对系、总对集、详对单——需求分析对系统测试，总体设计对集成测试，详细设计对单元测试。
雅
小雅
可以，就这么背。考试问「瀑布 V 模型中需求分析阶段对应的测试阶段是」，选项放单元测试、集成测试、系统测试、确认测试四个，答系统测试。注意那个干扰项「确认测试」——确认测试是生命周期国标里的阶段名，不在这张 V 字对应表里，专门钓那些把两套体系背串的人。另外 V 模型整体的评价也要会：瀑布 V 模型不但保持了瀑布模型的阶段式文档驱动的特点，而且更强调了软件产品的验证工作——「更强调验证」四个字是 V 模型的身份证。
明
阿明
V 模型算修补，那瀑布的病根呢？
雅
小雅
原文说得很清楚：即使在改进的瀑布 V 模型中，瀑布的缺陷还是会存在。四条，逐条记。第一，需求放大问题：在瀑布模型中，需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果导出的；一旦需求分析的结果不完全正确、存在偏差，后续的活动只能放大这个偏差，在错误的道路上越走越远。事实上，由于用户和开发者的立场、经验、知识域都不相同，需求分析的结果不可能精确、完整地描述整个软件系统，所以瀑布模型后期的维护工作相当繁重，而这些维护工作大多是在修正需求分析阶段引入的缺陷。
雅
小雅
第二，难以适应变化：瀑布模型精确地定义了每一个阶段的活动和活动结果，而每一阶段都紧密依赖于上一阶段的结果，如果在软件的后期出现了需求的变化，整个系统又要从头开始。第三，交付周期太长：使用瀑布模型意味着当所有阶段都结束才能最终交付软件产品，提出需求后需要相当长一段时间的等待才能看到最终结果，才能发现软件究竟满不满足客户的需求。第四，重载：文档驱动型的瀑布模型除了制造出软件产品外还将产生一大堆的文档，大部分文档对客户没有任何意义，但完成它们却需要花费大量人力，所以瀑布模型也是一种重载过程。
明
阿明
等下，「重载过程」这个词后面还会出现吧？我记得 UP 那边也有。
雅
小雅
会，而且考过原题——「一般认为未经裁减的 UP 是一个重载过程」。所以重载这个词你就记成：文档多、流程重、仪式感拉满。瀑布是重载，没裁剪的 UP 也是重载，敏捷整体上就是反重载。这条线贯穿全章。
明
阿明
四条缺点我归纳一下：放大需求偏差、难适应变化、等太久才能见到产品、文档太多是重载。
雅
小雅
归纳到位。补一个应试细节：出题人喜欢把「优点」和「缺点」混着考，比如「以下关于瀑布模型的描述错误的是」，选项里放一条「瀑布模型支持用户需求的动态变化」——这条是螺旋模型相对瀑布的优点，放在瀑布身上就是错项。看到瀑布，就想想那艘航母：图纸先画死，再施工。
明
阿明
明白了。那瀑布之后，业界怎么补救的？
雅
小雅
下一集就讲这个：人们意识到人的认知本身是渐进的、不断深化的，复杂问题「做两次」肯定做得更好，于是有了演化模型，由它演变出螺旋、增量、原型法，再加上搭积木的构件组装模型——四个模型一集讲完，每个都给你配身份证和考点。
雅
小雅
本集必背清一遍：GB8566-88 把软件生命周期划分为 8 个阶段——可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护；详细设计不是必需阶段；集成测试又称组装测试；瀑布是阶段划分明确、面向文档的开发模型，需求明确稳定时适用；V 模型在编码与调试处转弯，需求分析对系统测试、总体设计对集成测试、详细设计对单元测试，更强调验证；瀑布四大缺点——放大需求偏差、难以适应变化、交付等待长、重载过程。
明
阿明
收到，我先去把这八个阶段默写一遍，再听下一集。