03 | 到底应该怎样理解软件工程
有人参与、有计划、有步骤地造一件产品，我们通常称为“工程”。
所有工程的本质，就是要做出有用的产品，比如造房子的建筑工程、造火箭的航天工程。像网红“手工耿”一样专搞无用发明的情况，我们是不能称为“工程”的。在软件领域，对应的就是“软件工程”，这些我们日常使用的软件背后，都是基于软件工程的方法在开发、运行和维护的。
一、什么是软件危机？
也许有人会认为，不用软件工程，我一样可以开发软件出来。这确实没有错，因为如果一个人没有学过建筑工程，他也是可以造一个房子出来，只是造出来大概会是这个样子：
我们知道，不按照建筑工程造房子，是会出事故甚至死人的。
而在软件工程的历史上，也是真的有造成过很大损失、甚至还有人为之丧命的事件存在。OS/360 操作系统是上世纪 60 年代最复杂的软件系统之一，也是第一个超大型的软件项目，一共有 1000 名左右的程序员参与了项目的研发，花费了 5000 个人年，最终无法运行。项目负责人佛瑞德·布鲁克斯后来写了一本软件工程的经典书籍《人月神话》，承认在他管理这个项目的时候，犯了很多错误，造成了价值数百万美元的损失。如果是说 OS/360 还只是造成了经济损失的话，Therac-25 事件就是真的导致了人员死亡。Therac-25 是加拿大原子能有限公司（AECL）所生产的放射线疗法机器，在 1985 年到 1987 年之间，在美国及加拿大，至少有六起和 Therac-25 相关的医疗事故是因为程序 bug，导致部分病患受到比正常剂量高一百倍的辐射，因而造成患者重伤甚至死亡。
发生这些惨痛的事，原因却并不难理解。
在计算机刚发明出来的时候，计算机的能力非常有限，只能接收简单的指令和运算，不需要软件工程也可以开发出简单的软件。但是，当软件的规模越来越大，复杂度不断增加，软件项目开发维护过程中的问题就逐步暴露出来：软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。所以在 60 年代，“软件危机”的概念被提出来。
二、应对软件危机的办法—软件工程的概念被提出
为了解决“软件危机”，1968年北大西洋公约组织提出了“软件工程”这个概念。软件工程，它是为研究和克服软件危机而生。软件工程，就是要用工程化方法去规范软件开发，让项目可以按时完成、成本可控、质量有保证。
三、软件工程的演化史
对比传统的工程学科，和软件工程最接近的就是建筑工程了。设想一下建一座房子：首先要先立项、设定预算，然后画设计图，再是施工，施工完成后，由专业人士进行质量检查，质检合格后入住。开发软件本质上也是像盖房子一样，是从无到有创造的过程。工程化的方式，就是你分步骤（过程），采用科学的方法，借助工具来做产品。于是参考建筑工程，整个软件开发过程也被分成了几个阶段：需求定义与分析、设计、实现、测试、交付和维护，这也就是我们常说的软件项目生命周期。
当然，各个阶段都会有人的参与，于是产生了软件项目里的各种角色：项目经理、产品经理、架构师、程序员、测试工程师、运维工程师。
而对这整个过程的管理，我们通常称之为“项目管理”。同时，也很自然就衍生出一套最基础的过程模型：瀑布模型。
瀑布模型：
瀑布模型的详解：
用瀑布模型做项目就像古代匠雕刻玉石，先有完整的设计图，然后按部就班往前推进，中间不能出一点差错，追求的是“一次成型”。
这就是瀑布模型，最基本也最常用的一种项目管理模型，又称线性模型。
采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作。
瀑布模型的突出特征是文档驱动。从需求分析到系统维护，每一项活动的工作成果就是此项活动所产生的工作文档，以及在此基础上形成的产品。
瀑布模型最大的优点有两个：
1、每个阶段的开发质量都有保证，减少了返工。2、是文档细致，降低了沟通成本，有利于及早发现问题。
这就是开头说的雕刻玉石的步骤，有精细的设计图纸，每一步都不可行差踏错，因为一旦雕坏了，就得摔了玉重来。
这也正是瀑布模型的缺点：周期长，不易变更。
用户直到项目开发晚期才能了解产品的真实面貌和质量。这时候提出变更，成本会非常大。
适合采用瀑布模型的项目类型，通常是对用户需求非常明确的项目。同时还要求项目预算充足，人员齐备。
链接：https://zhuanlan.zhihu.com/p/116754890
瀑布模型的作用：
瀑布模型的诞生，在当时是有非常重大的意义的，让软件开发从无序到有序，让大家更好的分工协作，同时每个阶段又衍生出各自的方法学和工具，例如需求分析、软件测试等等。
瀑布模型的缺陷：
然而瀑布的特性决定了它只能从上往下流，而且从上到下走完整个周期很长，所以一旦出现了需求的变更，将会非常痛苦，很多事情需要重头再来。
瀑布模型的衍生：
于是基于瀑布模型，又衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷。这些改进模型的发展趋势上就是缩短项目周期，快速迭代。
敏捷联盟的出现：
这样到了 90 年代，各种轻量级开发方法例如 Scrum、极限编程等也不断被提出。到了 2001 年，这些轻量级开发方法一起组成了敏捷联盟，其后敏捷开发如同星星之火，逐渐形成燎原之势。
近些年，云计算、微服务这些新技术的产生，也对软件工程产生了影响。云服务让分工更细，很多企业可以将运维、服务器维护、DBA、甚至某些独立服务交给云服务商；微服务让大团队变成小团队，每个小团队可以更专注于细分领域，减少相互之间的依赖。
一个公式
当你大致了解整个软件工程的演变发展史，你会发现，软件工程的知识，都是建立在软件项目的过程，或者说软件项目生命周期之上的。基于软件过程，我们有了角色分工，有了对过程的管理和工具，对过程中每个阶段细分的方法学和工具。
现在，如果再回头看看我们的问题“什么是软件工程？”其实可以总结为：软件工程就是用工程化的方法来开发维护软件。
也可以说软件工程就是用一定的过程，采用科学的方法，借助工具来开发软件。如果用一个简单的公式表达，那就是：软件工程 = 过程 + 方法 + 工具。