软件开发模型
软件开发模型
原型模型
RAD模型
螺旋模型
原型模型
在进行了基本需求分析之后，快速开发出产品的原型，然后基于这个原型，同客户沟通、交流，更好地了解客户需求，不断修改这个原型，到了双方认可的程度，再做详细地分析、设计和编程，最终开发出令客户满意的产品。
一般步骤如下：
(1) 先定义软件的总体目标，根据已知的需求来规划出可实现的区域。
(2) 然后是“快速设计”，集中于系统的总体框架、基本功能和直观的输入方式和输出格式等。
(3) 有了原型，使客户对系统实现哪些具体功能、功能实现到什么程度有更好的理解。开发者可以边开发边评估，不断细化软件的需求，逐步调整原型使其满足客户的要求。这形成一个迭代的过程。
原型模型
即使开始建立的原型过于简单或性能很差，难以使用，但为下一次建立适用的模型积累了经验，而浪费的成本、时间有限。
原型模型的优点是使用户能够感受到实际的系统，使开发者能够快速地构造出系统的框架。
原型模型的缺点是产品的先天性不足，因为开发者常常需要做实现上的折中，可能采用不合适的操作系统或程序设计语言，以使原型能够尽快工作。
RAD模型
RAD（rap application development）模型，即快速应用开发模型。由于其模型构图形似字母“V”，故也称V模型，是属于线性顺序一类的软件开发模型。它通过使用基于构件的开发方法来缩短产品开发的周期，提高开发的速度。RAD模型实现的前提是能做好需求分析，并且项目范围明确，这一点正好和原型模型相反。RAD模型包含如下几个开发阶段。
RAD模型
(1) 业务建模：业务活动中的信息流被模型化。通过回答以下问题来实现：什么信息驱动业务流程？生成什么信息？谁生成该信息？该信息流往何处？谁处理它？
(2) 数据建模：业务建模阶段定义的一部分信息流被细化，形成一系列支持该业务所需的数据对象。标识出每个对象的属性，并定义这些对象间的关系。
(3) 处理建模：数据建模阶段定义的数据对象变换成要完成一个业务功能所需的信息流。创建处理描述以便增加、修改、删除或获取某个数据对象。
(4) 应用生成：RAD过程不是采用传统的第三代程序设计语言来创建软件，而是使用4GL技术或软件自动化生成辅助工具，复用已有的程序构件(如果可能的话）或是创建可复用的构件(如果需要的话)。
(5) 测试及反复：因为RAD过程强调复用，许多程序构件已经是测试过的，这减少了测试时间。但新构件必须测试，所有接口也必须测到。
RAD模型
RAD过程模型如图所示。很显然，加在一个RAD项目上的时间约束需要有“一个可伸缩的范围”。如果一个商业应用能够被模块化，使得其中每一个主要功能均可以在不到3个月时间内完成(使用上述的方法），它就是RAD的一个候选件。每一个主要功能可由一个单独的RAD组来实现，最后集成起来形成一个整体。
RAD模型
RAD模型
RAD模型还有一种改进型，将“编码”从V字型的顶点移到左侧，和单元测试对应，从而构成水平的对应关系。
RAD模型
从水平对应关系看
左边是设计和分析，右边是验证和测试。右边是对左边结果的检验，即对设计和分析的结果进行测试，以确认是否满足用户的需求。如：
需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，可以准备用例（use case）。
当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上要很长时间才能完成。
在做详细设计时，测试人员就可以准备测试用例（test case，以有效地发现软件缺陷的最小测试执行单元）。
一面编程，一面进行单元测试，是一种很有效的办法，使我们可以尽快找出程序中的错误。充分的单元测试可以大幅度提高程序质量、减少成本。
RAD模型
从图可以看出，RAD模型避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。RAD模型说明软件测试的工作很早就可以开始了，项目一启动，软件测试的工作也就启动了。
RAD模型
从垂直方向看
水平虚线上部表明，其需求分析、功能设计和验收测试等主要工作是面向用户，要和用户进行充分的沟通和交流，或者是和用户一起完成。水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行，由工程师完成。
所以RAD模型一般适合信息系统应用软件的开发，而不适合高性能、技术风险高或不易模块化的系统开发。如果一个系统难以被适当地模块化，那么就很难建立RAD所需的构件；如果系统具有高性能的指标，且该指标必须通过调整接口使其适应系统构件才能达到，使用RAD方法可能会导致整个项目失败。
螺旋模型
螺旋模型，最早是由Boehm提出来的，是一个演化软件过程模型，它将原型的迭代特征与线性顺序模型中控制和系统化方面结合起来，使得软件增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。在早期的迭代中，发布的增量可能是一个纸上的模型或原型；在以后的迭代中，更加完善的被开发系统版本逐步产生。
螺旋模型被划分为若干框架活动，也称任务区域。一般情况下，有3~6个任务区域。下图形象地描述了包含4个任务区域的螺旋模型。
螺旋模型
目标、选择和限制：系统要达到的目标，同时要受预算、时间等条件的限制，而且必须作出一定的选择和取舍。
风险评估：基于上述目标，评估技术及管理的风险，以决定如何实施项目。
开发和测试：包括系统需求分析、概要设计、详细设计、编程、单元测试、系统测试和验证测试等项目具体实施的各种任务。
计划：定义资源、进度及其他相关项目信息所需要的任务，以调整项目的目标和改善系统实施的效率。
螺旋模型
随着演化过程的开始，软件工程项目组按顺时针方向沿螺旋移动，从核心开始。螺旋的第1圈可能产生产品的规格说明；接续的螺旋可能用于开发一个原型；随后可能是更加完善的下一个版本软件。经过计划区域的每一圈是基于从用户评估得到的反馈，调整费用和进度。此外，项目管理者可以调整完成软件所需计划的迭代次数。
与传统的过程模型不同，在螺旋模型中，软件交付了并不意味着结束，其适用于计算机软件的整个生命周期。一个“概念开发项目”从螺旋的核心（水平轴）开始一直持续到概念开发结束。如果概念被开发成真正的产品，过程从水平轴一个新的起点开始，意味着一个新的开发项目启动了。
螺旋模型
本质上，具有上述特征的螺旋是一直运转的，直到软件退役。有时这个过程处于睡眠状态，但任何时候出现了改变，过程都会从合适的入口点（如产品增强）开始。
对于大型系统及软件的开发来说，螺旋模型是一个很现实的方法。因为软件随着过程的进展演化，开发者和用户能够更好地理解和对待每一个演化级别上的风险。螺旋模型使用原型作为降低风险的机制，更重要的是，它使开发者在产品演化的任一阶段均可应用原型方法。它保持了传统生命周期模型中系统的、阶段性的方法，但将其并进了迭代框架，更加真实地反映了现实世界。螺旋模型要求在项目的所有阶段直接考虑技术风险，如果应用得当，能够在风险变成问题之前降低它的危害。
螺旋模型
和其他模型一样，螺旋模型也不是十全十美的。它可能难以使用户（尤其在有合同约束的情况下）相信演化方法是可控的；它需要相当的风险评估的专门技术，且其成功依赖于这种专门技术，如果一个大的风险未被发现和管理，毫无疑问会出现问题；最后，该模型本身相对比较新，不像线性顺序模型或原型模型那样已经被广泛应用。
增量模型和迭代模型
软件开发不是一蹴而就，其过程犹如雕琢一件工艺品，由无形到有形、由粗到细，很难一次就能开发出功能完善、强大的一个版本，而往往是分阶段进行，一个版本接一个版本的发布。其主要原因是：
市场的压力和竞争策略的需要。较早地、不失时机地占领市场对软件企业是很重要的，如果软件企业用太长时间把一个完美的、功能强大的软件产品开发出来，可能市场已经被对手占领了。作为一个优秀的软件公司，会处理好市场策略和产品功能的平衡。
产品的开发预算是有限的，产品的开发周期和资源会受到预算的限制。
软件的复杂程度不断提高，增加了项目失败的可能性，将一个产品进行分阶段处理，可以尽早发现产品的市场问题或方向错误，降低风险。
软件的复杂程度不断提高，也使系统的分析和设计也变得非常困难。对于越来越复杂、庞大的系统，多数情况下，不容易一次性整体实现，而是通过分解逐步实现。
增量模型和迭代模型
所以软件在实际开发过程中是按阶段进行，逐步完善或深化系统的功能，如图所示。
软件分阶段开发示意图
增量模型和迭代模型
软件开发分阶段可以通过两种模型来描述，即增量模型和迭代模型。
增量模型 描述软件产品的不同阶段是按产品所具有的功能进行划分，先开发主要功能或用户最需要的功能，然后，随着时间推进，不断增加新的辅助功能或次要功能，最终开发出一个强大的、功能完善的、高质量的、稳定的产品。
迭代模型 描述软件产品的不同阶段是按产品深度或细化的程度来划分。先将产品的整个框架都建立起来，在系统的初期，已经具有用户所需求的全部功能。然后，随着时间推进，不断细化已有的功能或完善已有功能，这个过程好像是一个迭代的过程。最终的目标是一致的，也是为了实现一个强大的、功能完善的、高质量的、稳定的产品。
