软件生命周期模型

软件生命周期，同任何事物一样，一个软件产品或软件系统也要尽力孕育，诞生，成长，成熟，衰亡等阶段，一般称为软件生命周期(软件生存周期)。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实际参考。

• 瀑布模型

  瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该活动的工作对象作为输出，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动：否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值

  瀑布型简单地说就是按照需求，设计，编码，测试，软件维护这个基本地顺序来研发软件，前面一个步骤不完成，后面地步骤不能开始，否则问题会滚到下一个阶段，带来更多地问题

  优点：

  1. 为项目提供了按阶段划分的检查点
  2. 当前一阶段完成后，只需要去关注后续阶段

  缺点：

  1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
  2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险

  风险：

  1. 通过过多的强制完成日期和里程牌来跟踪各个项目阶段
  2. 瀑布模型的突出缺点是不适应用户需求的变化

• 原型化模型

  原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品

  严格的来说不算一种软件生命周期模型，他只是一种获取需求的方法。

• V模型

  v模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即个测试过程的各个阶段

  v模型的优点在于它非常明确的标识了测试过程中存在的不同级别，并且清楚地描述这些测试阶段和开发各阶段的对应关系

  用户需求-----------------------------------------验证，确认------------------------------------------------验收测试

  ​ 需求分析----------------------------- ------------------------------------------------------------------系统测试

  ​ 概要设计--------------------------------------------------------------------------------------集成测试

  ​ 详细设计----------------------------------------------------------------------单元测试
  ------------------------ -------------软件编码---------------------------------------------------------------

  V模型的缺陷及解决思路

  v模型仅仅把测试过程作为在需求分析，系统设计及编码之后的一个阶段，忽视了测试对需求分析，系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

  解决的思路，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

  优点：

  1. 每一个阶段都清晰明了，便于控制开发的每一个过程
  2. 既包含单元测试又包含系统测试

  缺点：

  1. 测试介入的比较晚，对于前期的一些缺陷无从发现和修改
  2. 测试和开发串行

• W模型

  相对于v模型，w模型更科学。w模型是v模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求，功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题

  优点：

  1. 测试伴随着软件地整个生命周期，例如，在需求分析结束后就可以进行需求分析测试
  2. 测试于开发是并行独立进行地

  缺点：

  1. 对有些项目，开发过程中根本没有文档产生，故w模型无法使用
  2. 对于需求和设计地测试技术要求很高，实践起来很难。

• 边做边改模型

  许多产品都是使用'边做边改'模型来开发的。在这种模型中，即没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

  在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

  这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

  1. 缺少规划和设计环节，软件的结构随着不断地修改越来越糟,导致无法继续修改
  2. 忽略需求环节，给软件开发带来很大地风险
  3. 没有考虑测试和程序地可维护性，也没有任何文档，软件地维护十分困难