软件工程过程 第3章 软件生存周期模型

模型的提出——编码修正模型、瀑布模型、增量模型、演化模型、统一过程模型、MSF模型

1.软件生存周期模型是指一个包括软件产品开发、运行和维护有关过程、活动和任务的框架，其中这些过程、活动和任务覆盖了从该系统的需求定义到系统的使用终止。P53

2.所有模型的内在基本特征.P53

描述了开发的主要阶段

定义了每一个阶段要完成的主要过程和活动

规范了每一个阶段的输入和输出（提交物）

提供了一个框架，可以把必要的活动映射到该框架中

3.传统软件工程过程模型的主要代表是编码修正模型、瀑布模型、增量模型、演化模型和螺旋模型。IBM公司的统一过程(简称RUP)、敏捷过程(AP)和微软解决方案(MSF)等则是现代软件工程模型的主要代表。P53

4.编码修正模型是所有模型中最为古老的也是最简单的模型，该模型将软件开发分为编码和测试两个活动。该模型特点如下:P54

最适用于很小且简单的项目

成本可能很低

易于使用，人员只需要很少的专业知识，任何写过程序的人都可以使用

对于一些非常小的、开发完后就会很快丢弃的软件可以采用

对于规模稍大的项目，采用这种模型是很危险的。由于缺乏预先的计划并且通常伴随着不正规的开发方式，容易导致代码碎片，交付的产品重量也很难保证。且因为设计没有很好地文档化，因此代码维护困难。

5.瀑布模型是典型的软/硬件开发模型。包括需求、设计、编码、测试、运行与维护几个阶段。每一个阶段交付产品为：软件需求规格说明书、系统设计说明书、实际代码和测试用例、最终产品、产品升级等。该模型主要特点如下：P54~P55

每一阶段都以验证/确认活动作为结束，其目的是尽可能多地消除本阶段产品中存在的问题。

在随后的阶段里，尽可能对前面阶段的产品进行迭代。

6.瀑布模型的优缺点。P55

   优点：

容易理解、管理成本低。

它不提供有形的软件成果，除非到生存周期结束时。但文档产生并提供了贯穿生命期的进展过程的充分说明。允许基线和配置早期接受控制。前一步作为下一步被认可的、文档化的基线。

    缺点：

客户必须能够完整、正确和清晰地表达其需要。但在系统开发中经常发现用户与开发人员沟通存在巨大差异、用户提出含糊需求又被开发人员随意解释，以及用户需求会随着时间推移不断变化等问题。

可能要花费更多的时间来建立一些用处不大的文档。

在开始的两个或者三个阶段，很难评估真正的进度状态。

在一个项目的早期阶段，过分强调了基线和里程碑处的文档。

开发人员一开始就必须理解其应用。

当接近项目结束时，出现了大量的集成和测试工作。

直到项目结束之前，都不能演示系统的能力。

7.V 模型是瀑布模型的一个变形，它在每一个环节都强调了测试，同时又在每一个环节都做到了对实现者和测试者的分离。V模型被广泛应用于软件外包中。

8.增量模型（增量生存周期模型）是由瀑布模型演变而来的，它是对瀑布模型的精化。该模型有一个假设，即需求可以分段，成为一系列增量产品，对每一增量可以分别地开发。在开始开发时，需求就很明确，并且产品还可以被适当地分解为一些独立的、可交付的软件，成为构造增量。在开发中，期望尽快交付其中的一些增量产品。P57~P58

9.增量模型的优缺点。P59

    优点：

第一个可交付版本所需要的成本和时间是很少的。

开发由增量表示的小系统所承担的风险是不大的。

由于很快发布了第一个版本，因此可以减少用户需求的变更。

允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。

    缺点：

如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定。

如果需求不像早起考虑到的那样稳定和完整，那么一些增量就可能需要重新开发、重新发布。

管理发生的成本、进度和配置的复杂性，可能会超出组织的能力。

10.演化模型显式地把增量模型扩展到需求阶段。为了第二个构造增量，使用了第一个构造增量来精化需求。

11.演化模型的优缺点。P60

    优点：

在需求不能予以规范时，可以使用这一演化模型。

用户可以通过运行系统的实践，对需求进行改进。

与瀑布模型相比，需要更多用户/获取方的参与。

    缺点：

演化模型的使用仍然处于初步探索阶段，因此具有较大的风险，需要有效的管理。

该方法的使用很容易成为不编写需求或设计文档的接口，即使需求或实际可以很清晰的描述。

用户/获取方不理解方法的自然属性，因此当结果不够理想时，可能产生抱怨。

12.螺旋模型中开发工作是迭代进行的，即只要完成了开发的一个迭代过程，另一个迭代过程就开始了。P60