【软考架构】我理解的软件过程模型

软件工程

从参考书上（5.1.1）不难看出，正如一些辅导机构讲师所描述的，“软件工程”这个专业名词如何定义至今都没有在业内达成共识。身为一名从土木工程（交通土建工程）“转码”过来的资深学渣，对于怎么理解“工程”这个已经沿用了数千年的古老名词倒是有一点入场优势。为了便于后续我解读“软件过程模型”的歪理能够自圆其说，先在这里陈述一下我理解的“软件工程”的定义，即：

运用一系列的方法、原则，去约束软件的设计、开发、运维，使其在质量、成本、产能等所有或部分方面趋于更优。

软件工程过程

工程作为宾语时，有一个非常常见的谓语——建设。每一项工程都会有一个整体性的客体作为建设的对象，例如桥梁工程就是建设一座桥，而软件工程的对象显然就是一套软件。需要向初学者们强调的是，在广义上：土建行业中无论是可行性报告还是主管部门的批文，都属于工程对象的一部分；同样的在软件工程中，需求规格说明书、设计图、接口文档甚至用户手册等非代码资料也应是软件的一部分。

基于此，针对参考书中的软件工程过程定义中的“软件工程过程是指为获得软件产品……”这个分句，我认为这里的“产品”应是包括了各种非代码资料的、广义的“软件产品”，也只有这样才能解释为什么后面的“活动”会包含“Plan——软件规格说明”和“Action——软件演进”，前者的产品是说明书，而后者则可以是升级（upgradation而不是upgrade） 等。

因此，软件工程过程是一系列活动，活动的主体是工程而非软件，软件是工程的对象而非过程的对象，它是过程的产物。

软件过程

作为一名Web全栈开发者，我是通过前端的VUE框架和微信小程序认识到“生命周期”这个概念的，与之紧密关联的是生命周期回调，或称钩子函数。而在后端PHP开发过程中，我早期使用的CodeIgniter3框架里也有钩子（Hooks）这一概念，该框架升级到4.0以后以事件（Events）替代了相关功能。归纳总结后，我理解的生命周期就是事物从无到有、维持存在、再从有到无的，并且能在同类的不同具体对象上周而复始的过程。根据这一定义，一切客观存在都有其生命周期。
在最新国标《系统与软件工程 软件生存周期过程》（GB/T 8566-2022）中，软件的生命周期被概括为概念、开发、生产、使用、支持、退役六个阶段。再结合参考书5.1.2第一段的描述，显然软件过程就是“软件”（广义上的）的生命周期，既不是“工程”的也不是“开发”的。

软件过程模型

不少人也称之为“软件工程模型”、“软件开发模型”，关于这个定义，在参考书中是这样描述的：

为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型被称为软件过程模型，有时也称之为软件生命周期模型。

首先我要质疑参考书中“工作模型”这一提法，在这个语境中，“工作”是一种活动，是不具备“外形”的、难以具象化的，对“式”或“法”的遵循要重于对“型”的参照。因而我认为这里用“工作模式”代替不仅从语义上更严谨，更重要的是有助于我们将开发、工程这些活动和软件、产品这些产物区分开来。之所以要把它们区分开，是因为我认为软件的生命周期虽然与工程活动紧密相连，但本质上二者还是有一些区别的，所以我不认为“软件过程模型”能与“软件工程模型”或“软件开发模型”完全画等号。

在软件工程这一章节的学习过程中，我发现不少人都遇到了和我一样的困惑：从工作模型的角度去看，不同的模型之间常常很难找到非常有说服力的、科学的、明确的区分界线。例如瀑布模型和原型化模型，二者之间似乎就是有没有“画草稿”的区别，而且采用瀑布模型真的是一点“草稿”都不“画”吗？另外，为什么敏捷模型下面可以有那么多方法，而且方法之间的区别甚至比模型之间的区别还大。我认为这些困惑的根源就在于将“模型”的主体定为了难以具象化的“工程”或“开发”工作活动，因此我想通过本文表达我似乎不太靠谱的主张：软件过程模型是塑造软件生命周期的模型，它的主体是软件，产物是线性的软件生命周期。

从软件的视角看，瀑布模型中的分析和设计阶段即使画了草稿也仍旧是概念形态，因为瀑布模型强调每一个后驱阶段都严格依赖前驱阶段的完整产物，因而软件的雏形自然要到实现阶段才开始显现。而原型化模型中“原型开发”这项工作使得软件多了一个“原型”形态，这就好像区分卵生动物和胎生动物一样将二者明显地、强说服力地区分开了。类似的，仅仅用一个“形态变化迅捷”就足以概括敏捷模型下各种方法的共性，并将敏捷模型与其它模型从本质上区分开。

我之所以说模型的产物是生命周期而非产品本身，是因为不同模型必然要产出有显著区别的产物，就像用不同的模子浇筑器件，即使都是用钢铁生产兵器，但生产矛和盾显然是两码事。当软件目标和施工条件相同时，采用不同模型得到的最终产品形态往往是大同小异甚至殊途同归，但生命周期的特征显然是各不相同的。

综上，我所理解的软件过程模型即：

软件从无到有、合零为整、由简化繁，以及维持存在、退役消亡等过程中，软件的整体或部件如何演化或更替的“模子”。在任意模型中，一个个“节点”是人的活动，伴随着软件的形态（概念、原型、代码等）、状态（开发、生产、异常等）、构成（功能、文档、用例等）的变化。经过这些变化，软件或成型、或终止，或进化、或退化，或由异常恢复正常，或由生产退向废弃，它们共同组成了时间维度上的软件生命线，这便是模型的产物——软件生命周期。
而分析、设计、编码、测试这些工作活动以及活动的规程、原则等则是“模子”的构件，它们构成模型并像模具约束铁水那样去约束软件的生命周期以使之呈现出不同的特征。至于模型的命名，既可以根据工作流的特征、也可以参考生命周期的特征，采用比喻、突出重点等各种方式，按照原创者的喜好命名（对，命名规范就是没有规范）。

以上歪理邪说只是一个半吊子架构师的胡言乱语，为了便于我理解式记忆而强词夺理式地胡编乱造出来的，仅供大家消遣，如果你觉得言之有理那纯粹是歪打正着。软件开发是一项极其需要创造力的工作，愚以为长远来看蓝领程序员是不可能有生存空间的，因此靠死记硬背最终必将被更先进的AI生产力所淘汰。正所谓“不管黑猫白猫，能捉老鼠的就是好猫”，如果有些并不很明晰的知识点一时难以理解，不妨试试按自己的理解“过度解读”一下？