常用软件开发模型比较分析（三）

7   WINWIN模型

WINWIN模型融合了螺旋模型的基本成分和原型实现的迭代特征，强调风险分析和标识。通过早期谈判使客户和开发者之间达成一致协议，它将变成进展到软件和系统定义的关键标准。WINWIN模型引入了3个里程碑，称为“抛锚点”。它可帮助建立一个生命周期的完全性，并提供在软件项目向前进展前的决策里程碑。采用WINWIN模型的软件过程如图1-9所示。

图1-9   采用WINWIN模型的软件过程

本质上，抛锚点表示了项目遍历螺旋时的3个不同的进展视图，第1个抛锚点称为“生存周期目标”，定义了一组针对每个主要软件工程活动的目标；第2个抛锚点称为“生存周期体系结构”，建立了当系统和软件体系结构被定义时必须满足的目标；第3个抛锚点称为“初始操作能力”，它表示一组目标，这些目标和将要安装／销售软件的安装前场地准备和将使用该软件的各方所需的帮助相关联。

WINWIN模型强调风险分析和标识，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。采用WINWIN模型的优点是客户和开发者达到一种平衡，实现双赢，但是需要额外的谈判技巧。

螺旋模型提出了强调客户交流的一个框架活动，该活动的目标是从客户处诱导出项目需求。在理想情况下，开发人员简单地询问客户需要什么，而客户提供足够的细节进行下去，不幸的是这种情形很少发生。而在WINWIN模型中，客户和开发人员进入一个谈判过程，客户被要求在成本和应市之间的约束下平衡功能、性能和其他产品或系统特征。最好的谈判追求“双赢”结果，即通过谈判客户获得大部分系统的功能，而开发人员则获得现实和可达到的预算和时限。

8   原型实现模型

原型实现模型从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出已知的需求，并规划出需要进一步定义的区域。然后是“快速设计”，即集中于软件中那些对用户／客户可见的部分的表示。这将导致原型的创建，并由用户／客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的要求，而同时也使开发者对将要做的事情有更好的理解。这个过程是迭代的，其流程从听取客户意见开始，随后是建造／修改原型、客户测试运行原型。然后往复循环，直到客户对原型满意为止。采用原型实现模型的软件过程如图1-10所示。

图1-10   采用原型实现模型的软件过程

原型实现模型的最大特点是能够快速实现一个可实际运行的系统初步模型，供开发人员和用户进行交流和评审，以便较准确地获得用户的需求。该模型采用逐步求精方法使原型逐步完善，即每次经用户评审后修改、运行，不断重复得到双方认可。这个过程是迭代过程，它可以避免在瀑布模型冗长的开发过程中看不见产品雏形的现象。其优点一是开发工具先进，开发效率高，使总的开发费用降低，时间缩短；二是开发人员与用户交流直观，可以澄清模糊需求，调动用户的积极参与，能及早暴露系统实施后潜在的一些问题；三是原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。

原型实现模型的缺点是产品原型在一定程度上限制了开发人员的创新，没有考虑软件的整体质量和长期的可维护性。由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计，因此原型实现模型不适合嵌入式、实时控制及科学数值计算等大型软件系统的开发。

增量模型和原型模型都是从概要需求出发开发的，但二者有明显不同。增量模型是从一些不完整的系统需求出发开始开发，在开发过程中逐渐发现新的需求。然后进一步充实完善该系统，使之成为实际可用的系统；原型开发的目的是为了发现并建立一个完整并经过证实的需求规格说明，然后以此作为正式系统的开发基础。因此原型开发阶段的输出是需求规格说明，这是为了降低整个软件生成期的费用而拉大需求分析阶段的一种方法，大部分原型是“用完就扔”的类型。

9   RAD模型

RAD（快速应用开发）模型是一个增量型的软件开发过程模型，强调极短的开发周期。该模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得了快速开发。如果正确地理解了需求，而且约束了项目的范围，利用这种模型可以很快创建出功能完善的信息系统。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。采用RAD模型的软件过程如图1-11所示。

图1-11   采用RAD模型的软件过程

RAD模型各个活动期所要完成的任务如下。

（1）业务建模

确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以辅之以数据流图。

（2）数据建模

为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可辅之以E-R图。

（3）过程建模

使数据对象在信息流中完成各业务功能，创建过程以描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理框。

（4）应用程序生成

利用第4代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成以构造出整个的应用系统。

（5）测试与交付

由于大量重用，一般只做总体测试，但新创建的构件还是要测试的。

与瀑布模型相比，RAD模型不采用传统的第3代程序设计语言来创建软件，而是采用基于构件的开发方法复用已有的程序结构（如果可能）或使用可复用构件和或创建可复用的构件（如果需要）。在所有情况下，均使用自动化工具辅助软件创造。很显然，加在一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到3个月的时间内完成，则其是RAD的一个候选者。每一个主要功能可由一个单独的RAD组来实现，最后集成起来形成一个整体。

RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。但是与所有其他软件过程模型一样，RAD方法有如下缺陷。

① 并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果有哪一个功能不能被模块化，那么建造RAD所需要的构件就会有问题。如果高性能是一个指标且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。

② 开发人员和客户必须在很短的时间内完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。

③ RAD只能用于信息系统开发，不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序的高互操作性时，这种情况就会发生。

 

 

转载：http://blog.chinaunix.net/uid-25063573-id-3035942.html