一、
软件工程按照经典的瀑布模型
1. 需求分析
2. 设计阶段
3. 实现阶段
4. 稳定阶段
5. 发布阶段
6. 维护阶段
事实上在现实世界中，软件工程师的职业发展与瀑布流程刚好相反
- 毕业进入公司（或者实习生），开始学习并维护一些已有的软件（维护阶段），主要由自己的师傅（Mentor）带领
- 能够在项目中改一些 Bug，然后发现发布小规模的更新版本（稳定/发布阶段），联系重构，开始和其他同事打交道
- 有机会负责重写一个较小的模块，没有多少文档，自己要写很多代码（实现阶段）
- 表现好的员工，有机会设计比较大的模块，自己写一些文档（设计阶段），和更多成员发生工作联系。在一些情况下还能发挥领导作用
- 员工逐渐成长为团队的骨干，有机会计划新的项目（需求分析）
现实生活中，学习的过程
Alpha 阶段
- 开始维护以前的同学开发出来的程序，理解程序，理解用户的痛点
- 找 Bug，改 Bug，重构小部分代码；一部分同学可以开发测试用例
- 在现有版本的基础上做少部分增量开发，快速分布并收集用户反馈
Beta 阶段
- 根据 Alpha 版本的反馈，进一步分析需求，估计实现需求的难度（此时应该能理解客户需求是什么）
- 设计 -> 开发（重构）
- 回归测试（用到上面开发的测试用例）
- 发布，收集用户反馈，看看新的版本是否真的解决了用户的问题
所以这种学习模式就像从瀑布下方一步一步上溯到源头，然后又从源头流下去，故称之为“大马哈鱼洄游模型”
2. 程序=数据结构+算法、 软件=程序+软件工程
客户们对程序员的需求从一个简单的程序，扩展到一个满足各种功能的应用软件，再扩展到一个能保证维修的软件服务
-
程序还要对数据进行操作，这些数据有些是静态的（例如软件的图标、提示信息），有些是动态的（例如程序生成的随机数字、程序通过网络下载的数据、用户的文字或语音输入等）
-
但是光有代码和静态数据还是不行，工程师要把它们构建为机器能懂的可执行代码。构建不仅仅是cc和link命令
-
一个复杂的软件不但要有合理的软件架构（Software Architecture）、软件设计与实现（Software Design, Implementation and Debug），还要有各种文件和数据来描述各个程序文件之间的依赖关系、编译参数、链接参数，等等。这些都是软件构建的过程
-
源代码管理（Source Code Control）的问题—有时候也叫配置管理（Software Configuration
Management） -
有一系列的工具和程序来保证程序的正确性，这些工具流程和程序本身应该更正确，才能保证别的软件的质量。这就是质量保障（Quality Assurance），具体的验证过程叫做软件测试（Testing）
-
软件团队要从需求分析（Re-quirement Analysis）开始，把合适的需求梳理出来，然后逐步展开后续工作，如设计（软件架构）、实现（写数据结构和算法）、测试，到最后发布软件
-
软件团队的人员也会流动，新的成员要尽快读懂已有的程序，了解程序的设计，这叫程序理解（Pro-gramComprehension）
-
软件在运行过程中还会出这样那样的问题，也许我们要时不时给软件打一个补丁，或者维护众多的服务器，团队的新老成员要一起工作，修复各种各样的问题，这叫软件维护（Software Maintenance），或者服务运营（Service Operation）
-
这一系列过程就是软件的生命周期（Software Life Cycle，SLC），有人得负责软件项目的管理（Project Management）
-
一个好的软件，即使功能和同类软件区别不大，但是会让人感觉到非常好用。这就是软件的用户体验（User Experience）。用户体验和数据结构、算法没有直接的关系，但是很多非常成功的软件就赢在这个方面
上面这些和软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容，是软件工程的核心部分。广义上的软件工程也包括用户体验、用户界面设计（User Interface Design）等。所以，一个推论是：
软件 = 程序 + 软件工程
一个扩展的推论是：
软件企业 = 软件 + 商业模式
程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。
2.1 软件开发的不同阶段
3. 软件工程定义
软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程
人们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想体系。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”。软件开发流程的目的是为了提高软件开发、运营、维护的效率，并提高软件的质量、用户满意度、可靠性和软件的可维护性
3.1 软件的特殊性
软件是可以运行在计算机及电子设备中的指令和数据的有序集合，软件有各种形式：
- 系统软件：操作系统、设备驱动程序、工具软件等
- 应用软件：用户使用它们来完成工作，从管理核电厂到写文章，或者是通信、游戏、浏览网页、播放视频等
- 恶意软件：软件病毒等软件
1. 复杂性（Complexity）
软件可以说是人类创造的最复杂的系统类型，软件的各个模块之间有各种显性或隐性的依赖关系，随着系统的成长和模块的增多，这些关系的数量往往以几何级数的速度增长
2. 不可见性（Invisibility）
工程师是“看”不到自己的源代码如何具体地在用户的机器上被执行的
3. 易变性（Changeability）
人们自然地期待软件能在下面两种情况下“改变”： a) 让软件做新的事情；b) 让软件适应新的硬件
4. 服从性（Conformity）
软件不能独立存在，它总是要运行在硬件上面，它要服从系统中其他组成部分的要求，它还要服从用户的要求、行业系统的要求
5. 非连续性（Discontinuity）
输入上很小的变化，会引起输出上极大的变化
3.2 软件工程与计算机科学的关系
| 计算机科学 | 软件工程 |
|---|---|
| 发现和研究长期的、客观的真理 | 短期的实际效果（具体的软件会过时） |
| 理想化 | 对各种因素的折衷 |
| 确定性、完美、通用性 | 对不确定性和风险的管理，足够好，具体的应用 |
| 各个学科独立深入研究，做出成果 | 关注和应用各个相关学科的知识，解决问题 |
| 理论的统一 | 百花齐放的实践方法 |
| 形式化，追求简明的公式 | 在实践中建立起来的灵感和直觉 |
| 正确性 | 可靠性 |
3.3 软件工程的目标——创造“足够好”的软件
软件的Bug多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。例如：
-
用户满意度：用户使用时发现了很多Bug，影响了用户使用软件的效率
-
可靠性：某个软件经常会崩溃，某个操作系统会时不时死机
-
软件流程的质量：软件团队和开发流程的问题太多，导致团队成员无法互相协作，按时交付软件。这也可以说是软件团队的Bug
-
可维护性：某个软件太难维护了，按下葫芦起了瓢，修复了一个问题，另一个问题又出来了。也没有足够的文档，维护人员表示需要更多的资金和时间来维护这个软件
软件工程三步曲
1. 研发出符合用户需求的软件说明
-
要通过实际的工作收集、推导、提炼需求，并在软件发布后通过实际数据验证需求的确被满足了
-
需求来自于实际，而不是自己想象出来的“需求”或者人云亦云的需求（例如：图书馆管理系统）
2. 通过一定的软件流程，在预计的时间内发布“足够好”的软件说明
- 这个软件是经历了一定的软件流程，通过全体团队成员的努力，在一个时间段内逐步完成的
3. 通过数据和其他方式展现所开发的软件是可以维护和继续发展的说明
-
例如，对用户需求有详细的分析，包括对将来这类软件发展的趋势的分析
-
主要功能都有设计文档，源代码完整，有修改记录，并有最后版本
-
关键模块有可以执行的单元测试、压力测试脚本，对于已知的bug和将来的工作都有详细的记录