对常用的软件开发模型的总结与个人理解_Phoenix-晶

对常用的软件开发模型的总结与个人理解

　   软件开发模型(SoftwareDevelopment Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。

　　软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

1.  瀑布模型-最早出现的软件开发模型

　　瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。

在现代过程方法XP（eXtreme Programming，极限编程）、RUP无一例外地都推荐、主张采用能显著减少风险的迭代模型。

对众多的开发模型和过程方法，及权威机构的看法，企业应选择什么样的开发模型，应慎重对从以下几方面进行考虑：

　　1、RUP虽然内容极其丰富，定义了选起、精化、构建、产品化4个阶段和业务建模、需求、分析设计、实现、测试、部署等9个工种，提供了一大堆的文档模板，但极易让人误解是重型的过程，实施推广有一定难度。

　　2、再次，在质量管理方面：以实现系统架构、核心功能目标的迭代产品生的工作成果作为质量控制重点。每次迭代进行系统集成、系统测试，达到对软件质量的持续验证。每次系统测试，需要回归测试前一次迭代遗留发现的问题。每次迭代发布的小版本组织客户（包括内部客户、外部客户）进行评价，通过演示操作等方式，评价该次迭代是否达到预定的目标，并以此为依据来制定下一次迭代的目标。

　　3、最后，在其他方面：每次迭代成果须进行配置管理，版本控制很重要。在整个迭代过程中风险无处不在，建议每周作一次风险跟踪。同时通过重点关注进度、工作量、满意度、缺陷等数据收集，关注每次迭代情况。  

迭代模型的选择使用条件

　　1、在项目开发早期需求可能有所变化。

　　2、分析设计人员对应用领域很熟悉。

　　3、高风险项目。

　　4、用户可不同程度地参与整个项目的开发过程。

　　5、使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。

　　6、使用CASE（ComputerAided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。

　　7、具有高素质的项目管理者和软件研发团队。

迭代模型的优点

　　与传统的瀑布模型相比较，迭代过程具有以下优点：

　　1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

　　2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

　　3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

　　4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

3.  螺旋模型　

为了确认形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发一个软件原型，用户可以从人机界面、系统主要功能和性能等几个方面对原型进行评审。必要时，可以修改软件需求、形式化规格说明和原型，直至原型被确认为止。这时软件开发人员即可对形式化的规格说明进行一系列的程序变换，直至生成计算机系统可以接受的目标代码。

“程序变换”是软件开发的另一种方法，其基本思想是把程序设计的过程分为生成阶段和改进阶段。首先通过对问题的分析制定形式规范并生成一个程序，通常是一种函数型的“递归方程”。然后通过一系列保持正确性的源程序到源程序的变换，把函数型风格转换成过程型风格并进行数据结构和算法的求精，最终得到一个有效的面向过程的程序。这种变换过程是一种严格的形式推导过程，所以只需对变换前的程序的规范加以验证，变换后的程序的正确性将由变换法则的正确性来保证。

变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（如设计、编码和测试等）。但是变换模型仍有较大局限，以形式化开发方法为基础的变换模型需要严格的数学理论和一整套开发环境的支持，目前形式化开发方法在理论、实践和人员培训方面距工程应用尚有一段距离。

5.  喷泉模型

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。采用喷泉模型的软件过程如图1-6所示。

图1-7  采用智能模型的软件过程

智能模型所要解决的问题是特定领域的复杂问题，涉及大量的专业知识，而开发人员一般不是该领域的专家，他们对特定领域的熟悉需要一个过程，所以软件需求在初始阶段很难定义得很完整。因此，采用原型实现模型需要通过多次迭代来精化软件需求。

智能模型以知识作为处理对象，这些知识既有理论知识，也有特定领域的经验。在开发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来（即知识获取），选择适当的方法进行编码（即知识表示）建立知识库。将模型、软件工程知识与特定领域的知识分别存入数据库，在这个过程中需要系统开发人员与领域专家的密切合作。

智能模型开发的软件系统强调数据的含义，并试图使用现实世界的语言表达数据的含义。该模型可以勘探现有的数据，从中发现新的事实方法指导用户以专家的水平解决复杂的问题。它以瀑布模型为基本框架，在不同开发阶段引入了原型实现方法和面向对象技术以克服瀑布模型的缺点，适应于特定领域软件和专家决策系统的开发。

7.  增量模型

增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如图1-8所示。

优点：尽早得到用户验证；能在早期识别风险，采取预防措施

缺点：没有考虑软件的整体质量和长期的可维护性，会给总体设计带来困难，削弱产品设计完全性；

适用用户需求模糊不明的情况下。

9.  原型实现模型

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

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

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

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

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

13.    RAD模型

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

图1-12  并发过程模型的一个活动

并发过程模型定义了一系列事件，对于每一个软件工程活动，它们触发一个状态到另一个状态的变迁。当它应用于客户机／服务器系统时，并发过程模型在两维上定义活动，即一个系统维和一个构件维。其并发性通过如下两种方式得到。

① 系统维和构件维活动同时发生，并可以使用面向状态的方法进行建模。

② 一个典型的客户／服务器应用通过多个构件实现，其中每个构件均可以并发设计并实现。

大多数软件开发过程模型均为时间驱动，越到模型的后端，就越到开发过程的后一阶段，而一个并发过程模型是由用户要求、管理决策和结果复审驱动的。并发开发模型在软件开发全过程活动的并行化，打破了传统软件开发的各阶段分割封闭的观念。强调开发人员团队协作，注重分析和设计等前段开发工作，从而避免了不必要的返工。其优点是可用于所有类型的软件开发，而对于客户／服务器结构更加有效，可以随时查阅到开发的状态。

15.    基于构件的开发模型

基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建，以及测试和发布5个阶段组成，采用这种开发模型的软件过程如图1-13所示。

图1-14  采用基于体系结构的开发模型的软件过程

在基于体系结构的开发过程中，首先是基于体系结构的需求获取和分析，将软件体系结构的概念引入到需求空间，从而为分析阶段到设计阶段的过渡提供更好的支持。在需求分析结果的基础上，进行体系结构的设计。考虑系统的总体结构及系统的构成元素，根据构成元素的语法和语义在已确定的构件库中寻找匹配的构件。当不存在符合要求的构件时，则根据具体情况组装合成新构件或者购买新构件或者根据需要开发新构件而得到满足需求的构件。在经过语法和语义检查后，将这些构件通过胶合代码组装到一起实现整个软件系统。在实践中，整个开发过程呈现多次迭代性。

在传统的软件生命周期中，软件需求分析和定义完成后紧接的是软件系统的设计和实现。在这种传统的开发方法中，如果软件需求不断变化，最终软件产品可能与初始原型相差很大。而基于体系结构的开发模型有严格的理论基础和工程原则，是以体系结构为核心。体系结构为软件需求与软件设计之间架起了一座桥梁，解决了软件系统从需求到实现的平缓过渡，提高了软件分析设计的质量和效率。

基于体系结构的开发模型的优点是通过对体系结构的设计，使得软件系统结构框架更清晰，有利于系统的设计、开发和维护，并且软件复用从代码级的复用提升到构件和体系结构级的复用。

基于体系结构的开发模型和基于构件的开发模型都是在体系结构的基础上进行构件的组装而得到软件系统，前者主要关注运行级构件及其之间的互操作性，提供了一种自底向上且基于预先定制好的构件来构造应用系统的途径；后者局限在构件的规范上，缺少系统化的指导开发过程的方法学。基于体系结构的开发方法从系统的总体结构入手，将一个系统的体系结构显示化，以在高抽象层次处理诸如全局组织和控制结构、功能到计算元素的分配、计算元素间的高层交互等设计问题。

17.    敏捷方法

敏捷方法是一系列方法的总称，虽然这些方法的名称、理念、过程、术语都不尽相同，但相对于“非敏捷”而言，它们更强调开发团队与用户之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队等，也更注重人的作用。敏捷方法强调，让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。产生这种情况的原因是，在绝大多数软件开发过程中，提前预测哪些需求是稳定的和哪些需求会变化非常困难；对于软件项目构建来说，设计和实现是交错的；从指定计划的角度来看，分析、设计、实现和测试并不容易预测；可执行原型和部分实现的可运行系统是了解用户需求和反馈的有效媒介。

目前，主要的敏捷方法有极限编程（eXtreme Programming，XP）、自适应软件开发（Adaptive Software Development，ASD）、水晶方法（Crystal）、特性驱动开发（Feature Driven Development，FDD）、动态系统开发方法（Dynamic Systems Development Method，DSDM）测试驱动开发（Test-Driven Development，TDD）、敏捷数据库技术（Agile Database Techniques，AD）和精益软件开发（Lean Software Development）和Scrum等。虽然这些过程模型在实践上有差异，但都是遵循了敏捷宣言或者是敏捷联盟所定义的基本原则。

敏捷方法主要适用于以下场合：

（1）项目团队的人数不能太多，适合于规模较小的项目。

（2）项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合。

（3）高风险项目的实施。

（4）从组织结构的角度看，组织结构的文化、人员、沟通性决定了敏捷方法是否适用。与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但是精干、开发人员所作的决定得到认可、环境设施满足团队成员之间快速沟通的需要。