总览
软件工程核心图：时间（多久可以完成）、范围（需要实现多少功能）、成本（花多少钱）决定了质量（产品的质量、客户的满意度）
软件工程核心知识：围绕软件开发过程，产生的方法学和工具
质量焦点：软件工程目标是聚焦于质量，构建和维护高质量的软件
过程：在软件项目的生命周期内开发与构建系统时要遵循的步骤（瀑布模型、敏捷开发）
方法：在整个过程中，如何构建系统的方法学（如何分析用户需求、如何对产品进行测试验收、如何进行系统架构设计等）
工具：知道了过程，掌握了方法，具体落到操作层面，就会涉及到工具的使用
软件工程 = 工具 + 方法 + 过程：
工程、软件工程
工程：有人参与、有计划、有步骤地造一件产品
工程的本质：有用的产品。无用的不能称为工程
软件危机：软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加
软件工程：为研究和克服软件危机而生
软件工程定义：
定义1：为了经济地获得在真实机器上可靠工作的软件而制定和使用的合理工程原则
定义2：将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程， 即将工程化应用于软件开发中
软件开发过程：：需求定义与分析、设计、实现、测试、交付和维护
软件工程核心：围绕软件项目开发，对开发过程的组织，对方法的运用，对工具的使用
过程模型1瀑布模型：让软件开发从无序到有序，让大家更好的分工协作，同时每个阶段又衍生出各自的方法学和工具，例如需求分析、软件测试等等
瀑布模型缺点：瀑布的特性决定了它只能从上往下流，而且从上到下走完整个周期很长，所以一旦出现了需求的变更，很多事情需要重头再来
改善：
基于瀑布模型，衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷；
这些改进模型的发展趋势上就是缩短项目周期，快速迭代
过程模型2敏捷开发：各种轻量级开发方法例如 Scrum、极限编程等不断被提出，这些轻量级开发方法一起组成了敏捷联盟
云：
云服务让分工更细，很多企业可以将运维、服务器维护、DBA、甚至某些独立服务交给云服务商；
微服务让大团队变成小团队，每个小团队可以更专注于细分领域，减少相互之间的依赖
工程思维
工程方法概念：有目的、有计划、有步骤地解决问题的方法
想法：想要解决的问题；
最开始问题通常是模糊的，所以需要清晰地定义好问题，研究其可行性，检查是否有可行的解决方案
概念：用图纸、草图、模型等方式，提出一些概念性的解决方案；
这些方案可能有多个，最终会确定一个解决方案
计划：关于如何实施的计划；
通常会包含人员、任务、任务持续时间、任务的依赖关系，以及完成项目所需要的预算
设计：针对产品需求，将解决方案进一步细化，设计整体架构和划分功能模块，作为分工合作和开发实施的一个依据和参考
开发：开发阶段就是根据设计方案，将解决方案构建实施；
开发阶段通常是一个迭代的过程，这个阶段通常会有构建、测试、调试和重新设计的迭代
发布：将最终结果包括文档发布
工程思维：本质上是一种思考问题的方式，在解决日常遇到的问题时，尝试从一个项目的角度去看待问题、用工程方法去解决问题、站在一个整体而不是局部的角度去看问题
瀑布模型
起源：一开始大家都是边写边改，产生了软件危机
瀑布模型：
好处：编码前先设计、编码后测试、整个过程重视文档，开发出来的产品质量相对是有保障的
缺点：不能及时响应需求变更，越到后期变更代价越大，且通常要到最后阶段才能看到结果是什么样子
快速原型模型
快速原型模型是为了要解决客户的需求不明确和需求多变的问题
先迅速建造一个可以运行的软件原型，然后收集用户反馈，再反复修改确认，使开发出的软件能真正反映用户需求，这种开发模型就叫快速原型模型，也叫原型模型。
针对原型模型快速、低质量的特点，通常有两种处理策略：抛弃策略和附加策略
抛弃策略：将原型只应用于需求分析阶段，在确认完需求后，原型会被抛弃，实际开 时，将重新开发所有功能；
附加策略：将原型应用于整个开发过程，原型一直在完善，不断增加新功能新需求，直到满足客户所有需求，最终将原型变成交付客户的软件；
采用哪种策略来应用原型模型要看项目特点，包括所采用原型开发工具和技术的成熟度；
如果客户对可靠性、性能要求高，可以采取抛弃策略；
如果客户对质量要求不高，有简单功能就够了，可以采取附加策略
大瀑布拆小瀑布
增量模型：
按模块来分批次交付，因此增量模型主要适用于需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。
迭代模型：
每次迭代都有一个可用的版本，最难的部分在于规划每次迭代的内容和要达到的目标
增量模型按照功能模块来拆分、迭代模型则按照时间来拆分，看单位时间内能完成多少功能
如果项目风险高，可能做一半就不做了，那么可以基于增量模型或者迭代模型进行开发，记得在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损，此为螺旋模型：强调风险，以风险驱动的方式完善项目的开发模型
敏捷开发
敏捷开发宣言：
根据这个价值观，产生了诸如站立会议、Scrum等工具
用敏捷开发的方式，不再像瀑布模型那样有严格的阶段划分，会在迭代中不断完善；
不再写很多文档，而是和客户一起紧密合作；
不再抵制需求变更，而是即时响应变更；
不再等到测试阶段才发布，而是随时发布，客户随时可以看到东西
最佳实践：Scrum + 极限编程 + 看板
Scrum 用来管理项目过程，极限编程用来工程实践，看板用来将工作流可视化
敏捷开发条件：
团队要小，人数超过一定规模就要分拆
团队成员之间要紧密协作，客户也要自始至终深度配合
领导支持:敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性
写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境
平衡质量、时间、成本
压缩时间：要求调整功能数量（调整范围）、增加开发成员（增加成本）
临时加需求：要求进度延期
MVP（minimum viable product，最小化的可行性产品）模式：是一种快速推出 产品的模式，一开始只推出最核心的功能，满足用户最核心的需求，然后在用户的使用过程中收集反馈，进一步升级迭代