前言：
在理解任何事物前，希望我可以养成一个对于这个事物提出3W1H（What？Why？Where？How？）的先行分析。再去高谈阔论云云~
我大学本科专业就是软件工程，当然也是上过《软件系统架构》这门课程，当时对于这门理论不能再理论的课程着实起不了半点儿兴趣（没有深度的理解吸收）。但是这两个月的求职阶段，抛开技术而言，大企业对于我本科阶段最看重的就是软件工程这样一种结构化的思维。
1. 什么是软件工程？（What？）
软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己认可的定义，这里我粘贴一下百度百科以及相关文章的定义：
- Barry Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
- IEEE：在软件工程术语汇编中的定义：软件工程是：1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；2.在1中所述方法的研究。
- 比较认可的一种定义认为：软件工程是研究和应用如何以系统性的、规范化的、可定量的工程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
以上定义可以看出，其实软件工程离不了软件的开发、运作以及后期维护三大环节。在这三个环节中，需要具备的就是一种工程化的思维方式去系统性的、规范化的、可量化的进行软件的全周期！其中，不仅仅限制于开发阶段，需要注意到软件整个项目中：周期有限、技术不断更新、需求不断变化、成本也是有限的这些环节。
2. 为什么会有软件工程？（Why？）
一般我认为3W中Why是最核心的问题，因为这是先行前提，也是问题或事物的根本。
当软件的规模越来越大，复杂度不断增加，软件项目开发维护过程中的问题就逐步暴露出来：软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。所以在60年代，“软件危机”的概念被提出来。
而软件工程提出来就是为了研究和克服“软件危机”的（1968年提出“软件工程”这一术语）！
3. 我们会在哪里运用到软件工程？（Where?）
在考虑这个问题的时候，我们首先要思考一下，软件项目中间有几个阶段？项目中又有几个哪些角色参与其中？
一般情况下，我们认定的软件项目生命周期为：需求定义与分析、设计、实现、测试、交付和维护
其次，软件项目参与角色包括：项目经理、产品经理、架构师、程序员、测试工程师、运维工程师
其实以上就是目前最为认可且常见的软件开发流程，绝大多数公司就是采用这种方式，进行软件开发与维护的，这不就是一种最为常见的软件工程的过程化方式吗？😎
4. 那我们应该怎么运用软件工程呢？（How？）
上文提到的软件项目生命周期，及参与角色衍生出了一套最为基础的过程模型：瀑布模型（如下图）
其后，当瀑布模型不能很好的应对需求的变更时，又衍生出了V模型、快速原型模型、增量模型、螺旋模型等等，试图改善瀑布模型存在的一些缺陷。这些改进模型的发展趋势上就是缩短项目周期，快速迭代。
这样到了90年代，各种轻量级开发方法例如Scrum、极限编程等也不断被提出。到了2001年，这些轻量级开发方法一起组成了敏捷联盟，其后敏捷开发如同星星之火，逐渐形成燎原之势。
此为，美国著名的软件工程专家巴利·玻姆 (Barry Boehm)于1983年提出了软件工程的七条基本原理。
- 用分阶段的生命周期计划严格管理
这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。
玻姆认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。
- 坚持进行阶段评审
统计结果显示：大部分错误是在编码之前造成的，大约占63%错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。
- 实行严格的产品控制
开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。
- 采纳现代程序设计技术
从六、七十年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大于气力。采用先进的技术既可以提高软件开发的效率，又可以减少软件维护的成本。（技术与时俱进）
- 结果应能清楚地审查
软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。
- 开发小组的人员应少而精
开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。 这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多；当开发小组为N人时，可能的通信信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。
- 承认不断改进软件工程实践的必要性
遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，玻姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。
5. 最后
近些年，云计算、微服务这些新技术的产生，也对软件工程产生了影响。云服务让分工更细，很多企业可以将运维、服务器维护、DBA、甚至某些独立服务交给云服务商；微服务让大团队变成小团队，每个小团队可以更专注于细分领域，减少相互之间的依赖。
当我们大致了解整个软件工程的演变发展史，会发现，软件工程的知识，都是建立在软件项目的过程，或者说软件项目生命周期之上的。
基于软件过程，我们有了角色分工，有了对过程的管理和工具，对过程中每个阶段细分的方法学和工具。
软件工程 = 过程 + 方法 + 工具