一.软件的生命周期
1.定义：生命周期指的式从生命的开始到生命结束的一段时间。以人为例，人类的生命周期是从生命孕育的开始，中间会经历幼年，童年，少年，青年，老年，最终直至死亡。
而软件/产品的生命周期也是如此，需求的开始是软件生命的起点，中间会经历需求的计划，设计，程序开发，程序测试等阶段，直至软件不再进行维护便到了生命的重点。
2.软件开发的生命周期
3.软件的生命周期中，每个阶段都是做什么的
阶段 | 具体内容 | 产出 |
需求分析 | 分析用户需求是否合理，分别从市场需求，技术等方面进行分析 | 该阶段会输出需求等文档 |
计划 | 对成立的需求执行需求执行计划，多长时间内完成该需求，每段时间具体完成哪些功能 | 该阶段会输出计划等文档 |
设计 | 将需求细化成一个个任务，团队成员各司其职领取任务并进行技术设计（如何进行架构设计，设计哪些接口，采用什么技术） | 该阶段会输出技术等文档 |
编码 | 开发人员参考需求文档，设计文档，交互图等等文件进行代码的编写 | 代码文件等文档 |
测试 | 测试人员需求介入到软件测试中来，参考测试用例对软件进行测试。 | 测试用例，测试设计与计划，测试报告等文档 |
运行维护 | 项目结束之后，项目需要进行上线，并对产品进行线上维护。线上的维护主要分为三个方面。分别为修复性维护，完善性维护和预防性维护。 修复性维护：对项目中未发现的问题进行修复 完善性维护：对功能进行完善。 预防性维护：居安思危，为了避免产品在线上出现一些其他不可预料的问题，进行一些防护手段 |
二.常见开发模型
1.瀑布模型
优点/特点：
1.强调开发的阶段性；
2.线性结构，每个阶段只执行一次
3.是其他模型的基础框架
缺点：
1.测试后置
前面各阶段遗留的风险推迟到测试阶段才发现，导致项目大面积返工，失去了及早修复的机会。
必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）
周期太长，产品很迟才能被看到和使用，可能会导致需求/功能过时。
适用场景：需求固定的小项目
2.螺旋模型
优点：
1.强调严格的全过程风险管理
2.强调各开发阶段的质量。
3.增加风险分析和原型
缺点：
1.项目中可能存在的风险性与风险管理人员的技能水平有直接关系。
2.需求人员，资金，时间的增加和投入，可能会导致项目的成本太高。
适用场景：规模庞大，复杂度高，风险大的项目
3.增量模型，迭代模型
增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。
增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的，可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改，构建出新的可执行软件的版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
与此类似地有一个迭代开发，增量开发和迭代开发往往容易被人，但是其实两者是有区别地，增量式逐块建造的概念，迭代是反复求精的概念
开发迭代是一次完整地经过所有工作流程的过程：(至少包括)需要工作流程，分析设计工作流程，实施工作流程和测试工作流程。实质上，迭代模型是类似小型的瀑布式项目。每一个迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
描述：
4.一次迭代过程包括了所有软件开发流程
5.每一次迭代均产生一个可发布的产品
6.该产品为最终产品的一个子集
适用项目于适合于事先不能完整定义产品的所有需求，计划多期开发的项目。
4.敏捷模型
(1)定义：敏捷模型主要旨在帮助项目快速适应变更请求。因此，敏捷模型的主要目的是促进项目的快速完成。要完成这项任务，需要敏捷。敏捷性是通过使过程适应项目，删除对特定项目可能不是必须的活动来实现。此外，避免任何浪费时间和精力事情。在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在小而已于管理，并且只能在几周内完成。一次性为客户计划，开发和部署一个迭代。没有制定长期计划。
（2)敏捷模型中的scrum模型
三个角色和五个重要会议
scrum由product owner(产品经理)，scrum master(项目经理) 和team(研发团队)组成。
其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
scrum master负责召开各种会议，协调项目，为研发团队服务。
研发团队则由不同技能成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
迭代开发
与瀑布不同，scrum将产品的开发分解为若干各小sprint（迭代），其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
scrum的基本流程如上图所示：
产品负责人负责整理user story,形成左侧的product backlog。
发布计划会议：product owner负责讲解user story,对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每各任务都有明确的负责人，并完成工时的初估计。
每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期待大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果。
敏捷中的测试：
轻文档和快速迭代
敏捷模型中强调轻文档，所以测试人员不应适用传统的excel编写测试用例的方法，更多的是使用思维导图，探索性测试（强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划，自动化测试等）
敏捷讲求合作，在敏捷项目组中，测试人员应多主动跟开发人员了解需求，讨论设计，一起研究bug出现的问题
5.测试模型中的V模型
V模型是瀑布模型的变种。
优点：
1.明确的标注了测试过程中存在不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系，有效提升测试的质量和效率。
V模型指出：
单元和集成测试应检测程序的执行是否满足软件设计的要求；
系统测试应检测系统功能，性能的质量特性是否达到系统要求的指标；
验收测试确定软件的实现是否满足用户需要或合同的要求
缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点同瀑布模型
6.W模型（双V模型）
W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
特点：测试的对象不仅是程序，需求设计等同样要测试，测试与开发是同步进行的
优点：
有利于尽早地全面发现问题。例如，需求分析完成后，测试人员就应该参与到对需求地验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
缺点：
需求，设计，编码等活动被视为串行的；
测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
也可以看一下下面的这篇文章，本文章迭代模型部分出自下面这篇文章。
软件开发模型总结归纳(瀑布模型、螺旋模型、迭代模型、增量模型、敏捷模型)_瀑布型 迭代型 增量型 敏捷型的区别-CSDN博客
