软件生命周期模型zz

    我们把软件的开发过程分成了这样几个阶段：需求规格阶段，概要设计阶段，详细设计阶段，代码阶段，单元测试阶段，集成测试阶段，以及系统测试阶段。也就是 说，在实际的开发过程中，我们要逐一完成每个阶段的工作，当完成最后一个阶段的工作后也就完成了整个软件项目。像这样组织软件开发过程的规则，就可以称为 软件生命周期模型。一个定义良好的软件生命周期模型，可以很好的指导我们的开发工作，使漫长的开发工作易于控制。事实上，我们可以任意定义自己喜欢的软件 生命周期模型。但是，如果生命周期模型定义不合理，却会制约我们的开发过程。软件开发人员在长期开发过程已经总结出了几种常用的软件生命周期模型，我们可 以根据项目的特点来选择一个合适的模型，然后在此基础上再加以裁减。这些生命周期模型是：
1）瀑布模型，
2）快速原型模型，
3）渐增模型，
4）演进模型。
下面我们重点阐述前3种常用的生命周期模型。
 
2．1瀑布模型
   顾名思义，该模型就是像瀑布一样。这是一个最传统的生命周期模型，是一种顺序的模型，自顶向下把一个软件开发过程分为：系统定义、需求分析、设计、编码、 测试和维护等阶段。在开发过程中这些阶段顺序进行，就像是一个飞流直下的瀑布，因此得名。该模型可以用下面的图形来表示。
        系统定义
          /|/
        需求分析
          /|/
         设计
          /|/
         编码
          /|/
         测试
          /|/
         维护
   有时，根据项目的特点，设计又可分为概要设计和详细设计。
  上图中各阶段所要完成的工作在一般的论述软件工程的书籍中都有描述，这里就不再细述。
  虽然上面的阶段是顺序进行的，但是这并不是限定我们的软件项目必须在完成了上个阶段的工作后才能进行下个阶段的工作。在实际的开发过程中，我们常常会遇到这样的情况：阶段反复和重叠。
   在前面的需求管理部分我们曾经阐述过需求变更管理。也就是说，在软件开发的某个阶段可能发生需求变更，而一旦软件需求发生变化，就势必会造成软件设计的改 变，因此，如果该软件项目已经进行到了测试阶段，那么我们就必须回过头来重新进行需求分析、概要设计、详细设计和编码。像这种在后面的阶段又返回来做前面 阶段工作的情形，就成为阶段反复。当然，也有可能因为开发人员前面的工作做得不够准确而导致阶段反复。阶段反复常常会造成进度延迟，但是，只要严格控制好 每个阶段的输入和输出，我们还是可以有效的控制软件项目的开发过程。
  在实际的开发过程中我们还会遇到这种情况：如果一个软件项目规模较大，而 且各功能模块相对独立，那么，我们就没有必要要求所有模块的进度都一致，也就是说，模块1可能很快就能完成概要设计和详细设计，而模块2由于太复杂概要设 计可能就需要很长的时间。对于这种情况，只要控制好模块1各阶段的输入和输出，完全可以让模块1先行，直到完成或者必须停下来等待其他模块。像这种情况， 一个软件项目的各模块可能处于不同的阶段，就成为阶段重叠。出现这种情况，必须是某些模块比较独立，否则就不可能比其他模块先行。
  虽然阶段的 重叠和反复是允许的，但是我们却不能允许这种情况随意发生。比如说，需求分析和设计可以重叠，但是如果需求分析和编码也重叠就很难说代码会写成什么样了； 编码阶段可以因为需求变更回过头来进行需求分析和设计，但是如果已经进行系统测试了还在进行阶段反复，这就等于又开发一个新项目了。因此，为了更好的控制 软件开发过程，要尽量减少阶段重叠和反复，如果实在不可避免，应该对所有的变更进行严格控制，这样才能保证我们的开发过程陷入无序状态。
  另外，在该模型的基础上，还衍生出了强调测试活动的V模型。它把瀑布模型的测试阶段进行细分，并于前面的阶段进行对应。细分出来的这些阶段分别为：单元测试阶段、集成测试阶段和系统测试阶段。V模型的结构图如下。
 
     系统定义                           维护
------/------------------------------/------------
 
         需求分析       .....       系统测试
              /                      /
            概要设计    .....   集成测试
                 /               /
               详细设计  ...  单元测试
                      /       /
                        编码
 
  与需求分析对应的是系统测试。因为需求分析的工作是分解用户的功能和性能需求并规格化，所以系统测试的工作主要就是测试这些功能和性能指标是否都在软件中正确实现。
该 测试把软件作为一个黑盒，针对每个需求规格组织各种输入并根据软件输出来判断该需求规格是否正确实现，因此系统测试属于黑盒测试。与概要设计对应的是集成 测试。因为概要设计的工作主要是根据功能把大的系统进行模块分解，所以集成测试的工作主要是，把各模块逐步集成在一起，来测试数据是否能够在各模块间正确 流动，以及各模块能否正确同步。因为这种测试依赖于软件的架构但又不关心每个函数的实现细节，所以该测试又常称为灰盒测试。与详细设计对应的是单元测试。 它主要是详细设计中的每个功能单元（通常是函数或过程）进行逻辑覆盖测试，因此这种测试属于白盒测试。与从需求到设计、统测试，于是就形成了一个V字形的 结构。
  与在瀑布模型中描述的一样，这些测试活动也是顺序进行的，并遵循一定的输入和输出规则（具体的测试在以后的章节中会详细描述），但是这些阶段也同样可以重叠和反复。
 
  瀑布模型的优点是清楚地标识出了软件开发的阶段。它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程。当所有的阶段都完成之后，该软件的开发过程也随之结束。
  瀑布模型的缺点正是它自身的顺序性所导致的。实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程。
  实际的开发过程中，用得较多的就是瀑布/V模型，只是可以根据实际需要进行阶段合并与裁减。