软件的生命周期：
需求分析----计划----设计----编码----测试----运行维护

瀑布模型

线性顺序进行的软件开发模式
**优点：**强调开发的阶段性
**缺点：**依赖于早期进行的唯一一次需求调查，不能适应需求变化；前期阶段的缺陷到后期测试才能发现，风险推迟到了后期测试阶段才显露，失去及早纠正的机会。
适合比较稳定的项目

螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模型，螺旋模型是渐进式开发模型的代表之一。
适合规模庞大，复杂度高，风险大的项目，这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟着开发的迭代而迭代。因此回归测试在渐进式模型中非常重要。

优点：
&emsp:强调严格的全过程风险管理。
&emsp:强调开发阶段的质量
&emsp:提供机会检讨项目是否有价值继续进行下去。
缺点：
引入风险识别，风险分析，风险控制，这对风险管理技能水平提出了很高的要求

增量、迭代

增量、迭代模型是软件开发过程中、常用的开发模型。

**其中的增量是指软件开发过程中，先开发主要功能模块，再开发次要功能模块，逐步完善，最终开发出符合需求的软件产品。**比如，需要开发一个类似WORD的软件，应该首先开发出文件管理（保存、读取文件）、基本编辑功能、打印等，而其它不太常用的功能可以最后开发。

**迭代是指增量开发过程中，各模块的开发是反复进行的，并不是完成了某个模块后就终止该模块的开发转而开发下一个模块。**以上面的开发WORD为例，比如，现在已开发了文件管理模块，正在开发编辑模块，但后来发现，文件管理模块有某些功能还没有实现，可以在编辑模块的开发过程中同时继续开发文件管理模块，如此不断的反复，所以说这个过程是迭代的过程。经过这样的反复迭代后该软件的功能就会越来越完善，最终开发出优秀的产品。

敏捷开发模型

==敏捷开发是一种应对快速变化的需求的一种软件开发能力。==强调程序员团队与业务专家之间的紧密协作、面对面沟通，（认为沟通比书面文档更有效）、频繁交付新的软件版本，能够很好的适应需求变化的代码编写和团队组织方法，注重软件开发中人的作用。

敏捷的宣言：
（1）人和交互重于过程和工具
（2）可用的软件重于完备文档
（3）客户协作重于合同谈判
（4）响应变化重于遵循计划
以上四点总结起来就是：重于人与人之间的沟通、轻文档、客户参与、拥抱变化

敏捷开发有很多种方式，其中scrum是比较流行的一种。

scrum

1、scrum里面的角色
scrum由product owner（产品经理）、scrum master（项目经理）和team（研发团队）组成。
product owner：负责 user story(用户故事)、定义其商业价值，对其进行排序，指定发布计划，对产品负责。
user story是用户需求的简化表达，用一两句话表达完整的想法。
scrum master：负责召开各种会议，协调项目，为研发团队服务。
研发团队：由不同技能的成员组成，通过紧密合作，完成每一次迭代的目标，交付产品。

scrum将产品的开发分分解为若干个小script（迭代），其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每期迭代会产生一定的交付。
2、scrum的基本流程

（1）产品经理负责整理user story，形成product backlog（按优先顺序排列的一个产品需求列表）
（2）scrum team根据Product Backlog列表，做工作量的预估和安排；
（3）迭代计划会议： 有了product backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议）来从中挑选一个story作为本次迭代完成的目标，这个目标的周期是1~4周，然后把这个stroy进行细化，形成一个sprint backlog；
（4）sprint backlog是由研发团队区完成的，每个成员根据sprint backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）
（5）每日例会： 研发团队完成计划会议上选出的sprint backlog过程中，需要进行Daily Scrum Meeting(每日站立会议)，每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，
（6）演示会议： 当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）
（7）回顾会议： print Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮sprint的产品需求中；

敏捷中的测试

敏捷中的测试有两个挑战：
挑战1：轻文档
挑战2：快速迭代
（1）测试工作的核心内容没有改变，不断地找bug，一切以敏捷为主
（2）测试人员不能依赖文档，测试用例的作用减弱，更多采用思维导图、探索性测试（强调自由度，设计和执行同时进行，根据测试结果不断地调整测试计划）、自动化测试
（3）敏捷讲求合作，再敏捷项目组中测试人员应该更主动点，多项开发人员了解需求、讨论设计，一起研究bug出现的原因。