（一）传统软件工程：
分析→设计编码→测试→维护
（二）现代软件工程
1、OOA面向对象 OOD、设计方法等
2、CMMI 软件成熟度模型
CMMI 5：优化级 特征：关注持续过程改进
CMMI 4：量化管理级 特征：关注组织量化
CMMI 3：定义级 特征：关注组织过程的标准化
CMMI 2：管理级 特征：关注基本的项目管理
CMMI 1：初始级 特征：混乱无序
（三）软件生命周期
可行性分析 →需求分析→设计→编码→测试→ 维护
（四）软件开的模型
1）瀑布模型
? 瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水逐级下落，最终得到软件产品。
?瀑布模型的核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为可行性研究与计划、需求分析、设计、编码、测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。如果需求发生变化，而需要逐级返回，修改所有相关的文档及代码。
优点：
?为项目提供了按阶段划分的检查点。
?当前一阶段完成后，才需要去关注后续阶段。
缺点：
?在项目各个阶段之间极少有反馈，它们之间依靠文档来传达所有信息。
?只有在项目生命周期的后期才能看到软件产品。
?通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
?瀑布模型的突出缺点是不能有效地适应用户需求的变化。
2）原型模型
?在项目开发的初始阶段，人们对软件的需求认识往往不够清楚，因而使得开发项目难以做到一次开发成功，出现返工再开发在所难免。
?原型模型的基本思想：在获得用户基本需求说明的基础上，投入少量人力和物力，快速建立一个原始模型，使用户及时运行和看到模型的概貌和使用效果，并对需求说明进行补充和精化，提出改进意见，开发人员进一步修改完善，如此循环迭代，直到得到一个用户满意的模型为止。
优点：
?改进了用户和软件开发人员的信息交流方式
?对用户需求的变化响应较快，用户满意程度提高
?开发出的软件产品能更好地满足用户的要求
?减少了用户培训时间，简化了管理
缺点：
?开发者为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段，软件系统的组
成部分可能会打折扣。
?资源规划和管理较为困难，随时更新文档也带来麻烦。
?解决复杂系统和大系统问题很困难。
一般使用场合：
?开发者在不了解的应用领域开发
?客户不清楚其所开发软件项目的最终目标。
**原型模型仅用于小项目
3）增量模型
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品。增量模型是一种非整体开发的模型。是瀑布模型的顺序特征和快速原型模型的迭代特征相结合的产物。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
增量模型可使用户在使用某些基本功能的同时，开发剩余的功能。这样通常会并行地存在两个系统：生产系统和开发系统。生产系统（或运行系统）是当前被客户或用户所使用的系统。而开发系统是准备用于替代当前生产系统的下一个版本。
优点：
如果在项目既定的商业要求期限不可能找到足够的开发人员，这种情况下增量模型显得特别有用。早期的增量可以由少量的人员实现。同时，增量模型可以规避技术风险。
缺点：
?由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
?在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
4）迭代模型
每次只设计和实现这个产品的一部分, 逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如 3 周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。
优点：
?允许变更需求
?尽早降低风险
?持续的测试和集成
?生成更高质量的产品
?有助于提高团队的士气
?提高复用性
注：迭代模型与增量模型
假设现在要开发 A、B、C、D 四个大的业务功能，每个功能都需要开发两月的时间。对于增量方法而言可以将四个功能分为两次增量来完成，第一个增量完成 A、B 功能，第二次增量完成 C、D 功能。而对于迭代开发来将则是分两次迭代来开发，第一次迭代完成 A、B、C、D 四个基本业务功能但不含复杂的业务逻辑；而第二次迭代再逐渐细化补充完整相关的业务逻辑。在第一个月过去后，采用增量开发的话 A、B 全部开发完成而 C、D 还一点都没有动；而采用迭代开发的时候 A、B、C、D 四个的基础功能都已经完成。现实中我们常常是把这二种模型整合一起使用，即增量迭代。
5）螺旋模型 （已经过时，在这不再多讲述）
6）统一开发过程模型
**7）敏捷开发模型（重点）
敏捷的出现缩小了商业需求和开发之间的隔阂，有效的加快了产品开发的周期和效率。开发和运维之间的隔阂需要解决，DevOps 的理念应运而生。
?软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长。
?敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品。所以，敏捷开发就是：一种以人为核心、迭代、循序渐进的开发方法 ! 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。
敏捷开发流程
①PO（Product Owner）和开发团队对产品业务目标形成共识；
②PO 建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序；
③PO 每轮迭代前，Review 需求列表，并筛选高优先级需求进入本轮迭代开发；
④开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成；
⑤开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明；
⑥PO 对每轮迭代（2－4 周）交付的可工作软件进行现场验收和反馈；
⑦回到第 3 步，开始下一轮迭代；
Scrum 迭代式增量软件开发
①什么是 Scrum？
Scrum 是一个包括了一系列的实践和预定义角色的过程骨架，通俗点说就是一种流程、计划、模式，用于有效率地开发软件。在生产过程中会设置若干冲刺节点，在每一次冲刺（一个 15 到 30 天周期 ，长度由开发团队决定），开发团队创建可用的（即可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品目标， 产品目标是指按照优先
级排列的需要完成的工作的概要的需求。哪些产品需求会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品项目中的哪些需求。开发团队决定在下一次冲刺中他们能够承诺完成多少产品需求。 在冲刺的过程中，没有人能够变更需求，这意味着在一个冲刺中需求是被冻结的。
Scrum 特点：Scrum 将小型团队转化为自身命运的管理者。
?强调每个人的主动性与参与性；
?快速实现“频繁变更的需求”；
?关注交付与产出的商业价值；
目的：促使整个开发过程迅速、自我驱动。
②Scrum 角色
Scrum 敏捷团队包括 3 个核心角色:
PO(Product Owner)
?传递来自市场的声音、提升项目的回报；
?确定产品 Backlog 中的优先级；
?从产品的角度确保团队工作方向。
Scrum Master(Scrum 教练)
?管理 Scrum 流程，确保 Scrum 运转；
?确保每个 Sprint 目标的实现与产出，不受外界干扰。
Team(技术团队)
?由 5-9 人组成（开发，测试等）、评估每个 Sprint 工作。
③Scrum 框架：
每日站立会：
?每天 15 分钟，团队面对面站立成圈
?晨会是为项目信息同步可视化,不是为了解决问题
?避免无关的讨论(SM 引导）
任务看板：
迭代结果的验收(Review)：
?团队需要演示所完成的迭代工作
?典型的做法是使用演示形式展示新功能或者底层架构的实现
?非正式的
?2 小时的提前准备
?不需要正式演示文档
?相关的利益相关者
?邀请所有关注产品的人参加
团队：
?Sprint 计划会议（Sprint Backlog）
?Daily 简会
?评审会议、总结
Product Backlog
?所有需要完成的产品清单，包括优先级、商业诉求，PO 负责
Sprint Backlog
?由团队主动选择完成的每个 Sprint 需要完成的 Story 列表
?每个 Story 包括了需求、优先级、工作量
?一旦确定，不亦更改
Sprint Burn down
?显示工作量趋势变化的图表
?每天由 Scrum Master 更新
注：Story 列表
故事是用来讲的、分享的、讨论的
?有价值：从商业的角度阐述（非技术术语）
?小、独立：简单的功能
?可讨论：关于故事的交流更重要
?动态的：伴随交流，确定细节、优先级
?优先级、需要交付的截止日期
?大需求可先写下大故事，再提炼、分解
（五）DevOps
开发团队要求的不断满足新的客户需求，并快速实现新的功能。而运营最关心的是“稳定压倒一切”，任何差错都有可能对生产环境中的用户造成直接影响。
如何解决开发和运维的隔阂
**Wikipedia 对 DevOps 的定义是：**DevOps 是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。
DevOps 并不仅仅关注软件部署，它是部门间沟通协作的一组流程和方法。
打破了目前的 RD->QA->OP 流水线的流程
例如：
RD 每次提交代码触发一系列的自动化步骤，包括编译，单元测试，代码覆盖率，功能测
试，部署测试，性能/容量测试，RD，QA，OP 都在过程中做质量保障。如图：
持续集成
持续集成的解决方案是简洁的。产品由 SVN（Git）去管理，构建过程由 CI server 负责，
而构建过程包含了编译，测试，发布，部署过程。
Tools：
?Automated infrastructure（自动化，系统之间可集成）
?shared version control（SVN 共享源码）
?one step build and deploy（持续构建和部署）
?feature flags（公司内部称为 single branch，主干开发）
?Shared metrics （指标度量工具）
?IRC and IM robots（信息整合）
（六）TestOps
TestOps 主要目的是推动整个研发体系与发布体系更多在质量方面。我们可以这样理解：DevOps 是从研发推动配合运维和测试，而 TestOps 是从测试角度推动研发和运维。所以TestOps 才是真正把测试落地到整个研发体系的关键岗位。
TestOps 定义：测试运维，测试角度推动研发、运维、持续测试到持续集成。
TestOps 技术栈
作为 TestOps 测试运维，其测试技能与运维技能都缺一不可，除了要负责需求的分析归纳，测试环境与生产环境的统一协调，还要解决测试脚本与构建平台的统一整合，确保测试能够在最短的时间内落地执行。这里就包括但不局限下列内容：
环境管理与监控：Docker、环境管理与监控：Docker、@TOCKubernetes、Ansible、Elk、Prometheus
版本管理：Git、Gitlab
构建：Maven、Nexus
测试：Xunit、Sonar、Selenium、Jmeter、Newman
发布：Jenkins