软件生命周期模型
软件生命周期模型
模型：定义了生命周期中要做的各项工作的规范和顺序。
瀑布模型
重点环节：
1、需求分析：需求规格文档
2、总体设计：概要设计文档
3、详细设计：详细设计文档
4、编码：写代码
5、测试：在编码完成后进行
优点：顺序清晰
缺点：
1、由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险
2、如果软件规模大，需求难以一次到位
V 模型
实现：顺序
测试：阶段划分
单元测试：测试单模块代码（开发做）
集成测试：测模块间的接口
系统测试：测试整体的系统
验收测试：用户参与的测试
项目验收测试：客户验收项目
产品验收测试：
阿尔法（α）测试：可控(公司内部)
贝塔（β）测试：不可控（公司外部的用户进行公测）
实现意义
V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。
从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。
左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。
用户需求 验收测试
需求分析和系统设计 确认测试和系统测试
概要设计 集成测试
详细设计 单元测试
编码
V模型问题
1.测试是开发之后的一个阶段。
2.测试的对象就是程序本身。
3.实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度。
双V模型W 模型
W模型由Evolutif公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
H模型
H模型中， 软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。
这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。也就是说， 只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。
H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备， 尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。
X模型
X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。已通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
敏捷开发模型
在瀑布开发模式的基础上进行了改进，最新从国外传播入国内，它还没有成熟，很多的开发团队都处于实践、探索的阶段。
概念
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
特点
敏捷最大的特色是迭代式开发。
敏捷开发最主要的特点就是：以人为核心、循序渐进。不再是非常详细的文档的编写，强调人与人面对面的交流;把一个项目分成许多的周期，每个周期都有自己需要完成的任务，并且是一定要完成。
管理工具
teambition
模型图
1、我们首先需要确定一个Product Backlog（产品需求列表），这个是由PO负责的；
2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
3、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
5、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。
6、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。
7、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
流程图
流程上主要是以下七点：
1、详细的产品需求列表，排定优先级，这些便需要产品经理来完成的工作，同时一般会有研发、UI、运营等人的配合;
2、工作量的评估：这一项需要技术人员的支持，同时也需要产品经理，内容就是沟通各方面的资源、权衡技术难度，制定详细的规划;
3、计划会议：这里是迭代的目标以及时间，同时把每一个大的任务细化到每个小任务——2、3天完成;
4、站立会议：每日开站立会议，每个人说明自己昨天完成了什么任务，今天要做什么，把已经完成的任务从未完成区域放在燃尽图的已完成区域;
5、做到每日集成，每天都有一个成功编译、并且可以演示的版本;
6、当一次迭代完成的时候，组织演示会议，也叫评审会议，邀请部门经理等管理者参加;
7、总结：轮流发言、讨论需要改进的地方，放入下一轮产品的需求中。
优缺点
优点：
1、迭代快，开发周期短;
2、不再耗费大量的时间来写文档，而是人与人面对面交流，只写一些必要的文档;
3、分工详细，每天都输出成果，客户能够看得到，会信任项目团队;
4、沟通多，容易发现问题，同时能够激起团队的协作、奋斗精神;
缺点：
1、人与人之间的信任是非常重要的环节，但是这个比较难完成，技术团队的成员可能技术能力差别大，同时也有互相竞争，又或者是项目团队的成员有所保留，不愿意这样的沟通;
2、团队在开发期间的任务多、压力大，需要时刻保持“兴奋”，一般很难做到。
