SDLC 软件开发生命周期 软件开发模型 4 增量模型(Incremental Model)
1.软件生命周期
软件生命周期是指软件从开始研制到最终被废弃所经历的各个阶段。在不同的阶段里，由不同的组织和人员执行不同的任务，需要消耗不同的资源。
生命周期常见的有：瀑布模型、V模型、敏捷开发模型。
阶段：需求分析->软件设计->程序编码->软件测试->运行维护
软件开发生命周期和流程
1.1瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，包括问题定义及规划、需求分析、软件设计、程序编码、软件测试和运行维护等六个基本活动，并且规定了他们自上而下，相互衔接的固定次序，形如瀑布流水，逐级下落，具有顺序性和依赖性，最终得到软件产品。
因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
每个阶段规定的文档需进行评审，评审完后才可以进入下一个阶段。
优点：
1）为项目提供按阶段划分的检查点
2）当前一阶段完成后，你只需要关注后一阶段
3）可在迭代模型中应用瀑布模型
4）提供一个模板，这个模板使得分析，设计，编码，测试和支持的方法可以在该模板下有一个共同的指导
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
1.2V模型
通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。其形状像一个字母A，故称为V模型。
对应关系：
一般来讲：单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；而系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。验收测试与用户需求对应，是非设计流程。
适用范围：
V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。
1.3敏捷开发模型
是一种以用户需求进化为核心（强调沟通、弱化文档）、迭代、循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
1.3.1敏捷开发的流程
1）产品负责人将整个产品设计成产品代办列表。就是一个个需求列表。（可以理解为需求或者要做的事情）
2）召开产品迭代计划会议，确定哪些需求是需要在第一个迭代中完成的，评估迭代的时间（建议是2-4周），得到相应的迭代周期任务列表。
PS:提前发布功能需求列表，会议提倡所有团队人员参与
3）把迭代的功能需求写在纸条上贴在任务墙，让大家（自主认领）认领分配。（任务墙就是把未完成、进行中、已完成的工作状态贴到一个墙上，这样大家都可以看到任务的状态）
- 举行每日站立会议，让大家在每日会议上总结昨天做的事情，遇到什么困难，今天开展什么任务。（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内）
- 绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0，这个迭代就完成了)
PS:在开发人员开始开发一个任务时，需要找来对应的测试人员讲解该任务功能，以便测试人员有一致的理解，并且一开始就进行测试用例，自动化系统测试脚本的开发（若需要自动化测试的话）。
4）评审会议是在迭代完成时举行，要向客户演示自己完成的软件产品，并获得客户的反馈。
PS:很多用户对软件开发是没有概念的，他只知道自己有某种需求。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。
5）最后是总结会议，以轮流发言方式进行，每个人都要发言，总结好的实践和教训，并落实到后续的开发中。不要流于形式。
1.3.2.敏捷开发适用原则
1、个人与互动：重于流程与工具
----强调人与人的沟通，所以尽可能要集中化办公。异地开发模式容易让人疲惫
个人技能要提高。尤其对于架构师要求很高。
管理者要多参与项目有关的事情。
减少对开发人员的干扰，问题集中整理问。
2、可用的软件：重于详尽的文件
----强调文档的作用。必要的文档是必须的，具有传承性。
3、与客户合作：重于合约协商
----做好客户引导。客户都是想在尽可能短的时间内，交付尽可能多的功能。
4、回应变化：重于遵循计划
----无理变化，举棋不定的结果，并不是说都需要及时响应，会导致很多浪费。
快速原型模型
流程：快速分析——》构造原型——》运行原型——》评价原型——》修改
优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
这种模型适合预先不能确切定义需求的软件系统的开发。
缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
螺旋模型
优点:
1）设计上的灵活性,可以在项目的各个阶段进行变更。
2）以小的分段来构建大型系统,使成本计算变得简单容易。
3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点:
很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而[软件]技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
①由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
②在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
例如，使用增量模型开发文字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。
也可以这样理解（来自唐老师课件）：
①将系统功能分解为互不重叠的子功能，它引进了增量包的概念，无须等到所有需求都出来， 只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。
②每次全力实现一个子功能。 由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。
③增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品
④子功能全部完成后系统开发结束。
4.1 优点
①人员分配灵活，一开始不需要投入大量人力
②先推出核心的产品，在后续增加相应的功能
③增量能够有计划的管理技术风险
④适用于需求经常变更的软件开发过程
4.2 缺点
①如果增量包之间存在相交的情况未很好的处理，则必须做全盘的系统分析
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。采用喷泉模型的软件过程如下图所示：
喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。