常用软件开发模型Word格式.docx
《常用软件开发模型Word格式.docx》由会员分享，可在线阅读，更多相关《常用软件开发模型Word格式.docx（23页珍藏版）》请在冰豆网上搜索。
这样软件与用户见面的时间间隔较长，也增加了一定的风险。
②在软件开发前期末发现的错误传到后面的开发活动中时，成整个软件项目开发失败。
可能会扩散，进而可能会造
③在软件需求分析阶段，
完全确定用户的所有需求是比较困难的，
甚至可以说是不太可
能的。
1.2.2螺旋模型
螺旋模型将瀑布和演化模型（EvolutionModel）结合起来，它不仅体现了两个模型的
优点，而且还强调了其他模型均忽略了的风险分析。
这种模型的每一个周期都包括需求定义、
风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。
软件开发过程每迭代一次，软件开发又前进一个层次。
采用螺旋模型的软件过程如图1-4所示。
图1-4采用螺旋模型的软件过程
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。
每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而
做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。
对于这些系统，风险是
软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产
品的质量。
减小软件风险的目标是在造成危害之前，
及时对风险进行识别及分析，
决定采取
何种对策，进而消除或减少风险的损害。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力。
并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。
但是，我们不能说螺旋模型绝对比其他模型优越，缺点。
事实上，这种模型也有其自身的如下
①采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，中，如果未能够及时标识风险，势必造成重大损失。
在风险较大的项目开发
②过多的迭代次数会增加开发成本，延迟提交时间。
1.2.3变换模型
变换模型是基于形式化规格说明语言及程序变换的软件开发模型，
开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换，
系统能够接受的程序系统。
采用变换模型的软件过程如图1-5所示。
它采用形式化的软件最后映射为计算机
图1-5采用变换模型的软件过程
为了确认形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发一个
软件原型，用户可以从人机界面、系统主要功能和性能等几个方面对原型进行评审。
必要时，
可以修改软件需求、形式化规格说明和原型，直至原型被确认为止。
这时软件开发人员即可
对形式化的规格说明进行一系列的程序变换，直至生成计算机系统可以接受的目标代码。
“程序变换”是软件开发的另一种方法，其基本思想是把程序设计的过程分为生成阶段和
改进阶段。
首先通过对问题的分析制定形式规范并生成一个程序，通常是一种函数型的“递
归方程”。
然后通过一系列保持正确性的源程序到源程序的变换，把函数型风格转换成过程
型风格并进行数据结构和算法的求精，最终得到一个有效的面向过程的程序。
这种变换过程
是一种严格的形式推导过程，所以只需对变换前的程序的规范加以验证，变换后的程序的正
确性将由变换法则的正确性来保证。
变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（如
设计、编码和测试等）。
但是变换模型仍有较大局限，以形式化开发方法为基础的变换模型
需要严格的数学理论和一整套开发环境的支持，目前形式化开发方法在理论、实践和人员培
训方面距工程应用尚有一段距离。
1.2.4喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软
件开发过程。
该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，
就
像水喷上去又可以落下来，
类似一个喷泉。
各个开发阶段没有特定的次序要求，
并且可以交
互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。
采用喷泉模型的软件
过程如图
1-6
所示。
图
采用喷泉模型的软件过程
喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。
各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。
由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。
该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
由于喷泉模
型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
1.2.5智能模型
智能模型也称为“基于知识的软件开发模型”，它把瀑布模型和专家系统结合在一起，利
用专家系统来帮助软件开发人员的工作。
该模型应用基于规则的系统，采用归纳和推理机制，
使维护在系统规格说明一级进行。
这种模型在实施过程中以软件工程知识为基础的生成规则
构成的知识系统与包含应用领域知识规则的专家系统相结合，构成这一应用领域软件的开发
系统。
采用智能模型的软件过程如图1-7所示。
图1-7采用智能模型的软件过程
智能模型所要解决的问题是特定领域的复杂问题，涉及大量的专业知识，而开发人员一般不是该领域的专家，他们对特定领域的熟悉需要一个过程，所以软件需求在初始阶段很难定义得很完整。
因此，采用原型实现模型需要通过多次迭代来精化软件需求。
智能模型以知识作为处理对象，这些知识既有理论知识，也有特定领域的经验。
在开发
过程中需要将这些知识从书本中和特定领域的知识库中抽取出来（即知识获取），选择适当的方法进行编码（即知识表示）建立知识库。
将模型、软件工程知识与特定领域的知识分别存入数据库，在这个过程中需要系统开发人员与领域专家的密切合作。
智能模型开发的软件系统强调数据的含义，并试图使用现实世界的语言表达数据的含义。
该模型可以勘探现有的数据，从中发现新的事实方法指导用户以专家的水平解决复杂的问题。
它以瀑布模型为基本框架，在不同开发阶段引入了原型实现方法和面向对象技术以克服瀑布
模型的缺点，适应于特定领域软件和专家决策系统的开发。
1.2.6增量模型
增量模型融合了瀑布模型的基本成分
（重复应用）和原型实现的迭代特征，
该模型采用
随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的
“增量”。
当使用增量模型时，第
1个增量往往是核心的产品，即第
1个增量实现了基本的需求，但
很多补充的特征还没有发布。
客户对每一个增量的使用和评估都作为下一个增量发布的新特
征和功能，这个过程在每一个增量发布后不断重复，
直到产生了最终的完善产品。
增量模型
强调每一个增量均发布一个可操作的产品。
采用增量模型的软件过程如图
1-8
增量模型与原型实现模型和其他演化方法一样，
本质上是迭代的，但与原型实现不一样
的是其强调每一个增量均发布一个可操作产品。
早期的增量是最终产品的
“可拆卸”版本，但
提供了为用户服务的功能，并且为用户提供了评估的平台。
增量模型的特点是引进了增量包
的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。
虽然某个增
量包可能还需要进一步适应客户的需求并且更改，
但只要这个增量包足够小，
其影响对整个
项目来说是可以承受的。
图1-8采用增量模型的软件过程
采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。
如果核心产品很受欢迎，则可增加人力实现下一个增量。
当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。
这样即可先发布部分功能给客户，对客户起到镇静剂的作用。
此外，增量能够有计划地管理技术风险。
增量模型的缺点是如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
1.2.7WINWIN模型
WINWIN模型融合了螺旋模型的基本成分和原型实现的迭代特征，强调风险分析和标
识。
通过早期谈判使客户和开发者之间达成一致协议，它将变成进展到软件和系统定义的关
键标准。
WINWIN模型引入了3个里程碑，称为“抛锚点”。
它可帮助建立一个生命周期的完
全性，并提供在软件项目向前进展前的决策里程碑。
采用WINWIN模型的软件过程如图1-9
图1-9采用WINWIN模型的软件过程
本质上，抛锚点表示了项目遍历螺旋时的3个不同的进展视图，第1个抛锚点称为“生存周期目标”，定义了一组针对每个主要软件工程活动的目标；
第2个抛锚点称为“生存周期体系结构”，建立了当系统和软件体系结构被定义时必须满足的目标；
第3个抛锚点称为“初
始操作能力”，它表示一组目标，这些目标和将要安装／销售软件的安装前场地准备和将使用该软件的各方所需的帮助相关联。
WINWIN模型强调风险分析和标识，使得开发人员和用户对每个演化层出现的风险有
所了解，继而做出应有的反应。
采用WINWIN模型的优点是客户和开发者达到一种平衡，实现双赢，但是需要额外的谈判技巧。
螺旋模型提出了强调客户交流的一个框架活动，该活动的目标是从客户处诱导出项目需求。
在理想情况下，开发人员简单地询问客户需要什么，而客户提供足够的细节进行下去，
不幸的是这种情形很少发生。
而在WINWIN模型中，客户和开发人员进入一个谈判过程，
客户被要求在成本和应市之间的约束下平衡功能、性能和其他产品或系统特征。
最好的谈判追求“双赢”结果，即通过谈判客户获得大部分系统的功能，而开发人员则获得现实和可达到的预算和时限。
1.2.8原型实现模型
原型实现模型从需求收集开始，开发者和客户在一起定义软件的总体目标，标识出已知
的需求，并规划出需要进一步定义的区域。
然后是“快速设计”，即集中于软件中那些对用户
／客户可见的部分的表示。
这将导致原型的创建，并由用户／客户评估并进一步精化待开发
软件的需求。
逐步调整原型使其满足客户的要求，而同时也使开发者对将要做的事情有更好
的理解。
这个过程是迭代的，其流程从听取客户意见开始，随后是建造／修改原型、客户测
试运行原型。
然后往复循环，直到客户对原型满意为止。
采用原型实现模型的软件过程如图
1-10所示。
图1-10采用原型实现模型的软件过程
原型实现模型的最大特点是能够快速实现一个可实际运行的系统初步模型，供开发人员
和用户进行交流和评审，以便较准确地获得用户的需求。
该模型采用逐步求精方法使原型逐步完善，即每次经用户评审后修改、运行，不断重复得到双方认可。
这个过程是迭代过程，
它可以避免在瀑布模型冗长的开发过程中看不见产品雏形的现象。
其优点一是开发工具先进，
开发效率高，使总的开发费用降低，时间缩短；
二是开发人员与用户交流直观，可以澄清模
糊需求，调动用户的积极参与，能及早暴露系统实施后潜在的一些问题；
三是原型系统可作
为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。
原型实现模型的缺点是产品原型在一定程度上限制了开发人员的创新，没有考虑软件的整体质量和长期的可维护性。
由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计，因此原型实现模型不适合嵌入式、实时控制及科学数值计算等大型软件系统的开发。
增量模型和原型模型都是从概要需求出发开发的，但二者有明显不同。
增量模型是从一些不完整的系统需求出发开始开发，在开发过程中逐渐发现新的需求。
然后进一步充实完善该系统，使之成为实际可用的系统；
原型开发的目的是为了发现并建立一个完整并经过证实
的需求规格说明，然后以此作为正式系统的开发基础。
因此原型开发阶段的输出是需求规格
说明，这是为了降低整个软件生成期的费用而拉大需求分析阶段的一种方法，大部分原型是“用完就扔”的类型。
1.2.9RAD模型
RAD（快速应用开发）模型是一个增量型的软件开发过程模型，强调极短的开发周期。
该模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法
赢得了快速开发。
如果正确地理解了需求，而且约束了项目的范围，利用这种模型可以很快
创建出功能完善的信息系统。
其流程从业务建模开始，随后是数据建模、过程建模、应用生
成、测试及反复。
采用RAD模型的软件过程如图1-11所示。
图1-11采用RAD模型的软件过程
RAD模型各个活动期所要完成的任务如下。
（1）业务建模
确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以辅之以数据流图。
（2）数据建模
为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可辅之以E-R图。
（3）过程建模
使数据对象在信息流中完成各业务功能，创建过程以描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理框。
（4）应用程序生成
利用第4代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成以构造出整个的应用系统。
（5）测试与交付
由于大量重用，一般只做总体测试，但新创建的构件还是要测试的。
与瀑布模型相比，RAD模型不采用传统的第3代程序设计语言来创建软件，而是采用
基于构件的开发方法复用已有的程序结构（如果可能）或使用可复用构件和或创建可复用的构件（如果需要）。
在所有情况下，均使用自动化工具辅助软件创造。
很显然，加在一个
RAD模型项目上的时间约束需要“一个可伸缩的范围”。
如果一个业务能够被模块化使得其中
每一个主要功能均可以在不到
要功能可由一个单独的RAD
3个月的时间内完成，则其是RAD
组来实现，最后集成起来形成一个整体。
的一个候选者。
每一个主
RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。
但是与所有其他软件过程模型一样，RAD方法有如下缺陷。
①并非所有应用都适合RAD。
RAD模型对模块化要求比较高，如果有哪一个功能不能
被模块化，那么建造RAD所需要的构件就会有问题。
如果高性能是一个指标且该指标必须
通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。
导致
②开发人员和客户必须在很短的时间内完成一系列的需求分析，
RAD项目失败。
任何一方配合不当都会
③RAD只能用于信息系统开发，不适合技术风险很高的情况。
当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序的高互操作性时，这种情况就会发生。
1.2.10并发开发模型
并发开发模型也称为“并发工程”，它关注于多个任务的并发执行，表示为一系列的主要
技术活动、任务及其相关状态。
并发过程模型由客户要求、管理决策，评审结果驱动，不是
将软件工程活动限定为一个顺序的事件序列，而是定义一个活动网络，网络上的每一个活动
均可与其他活动同时发生。
这种模型可以提供一个项目的当前状态的准确视图。
采用并发开
发模型的软件过程中一个活动的示意如图
1-12
图1-12并发过程模型的一个活动
并发过程模型定义了一系列事件，对于每一个软件工程活动，它们触发一个状态到另一个状态的变迁。
当它应用于客户机／服务器系统时，并发过程模型在两维上定义活动，即一个系统维和一个构件维。
其并发性通过如下两种方式得到。
①系统维和构件维活动同时发生，并可以使用面向状态的方法进行建模。
②一个典型的客户／服务器应用通过多个构件实现，其中每个构件均可以并发设计并实
现。
并发开发模型试图根据传统生命周期的主要阶段来追踪项目的状态，项目管理者根本不
可能了解项目的状态，因而需要使用比较简单的模型来追踪非常复杂的项目活动。
并发开发
模型使用状态图（表示一个加工状态）来表示与一个特定事件（如在开发后期需求的一个修
改）相关的活动之间存在的并发关系，但它不能捕获到贯穿于一个项目中所有软件开发和管
理活动的大量并发。
大多数软件开发过程模型均为时间驱动，越到模型的后端，就越到开发过程的后一阶段，而一个并发过程模型是由用户要求、管理决策和结果复审驱动的。
并发开发模型在软件开发
全过程活动的并行化，打破了传统软件开发的各阶段分割封闭的观念。
强调开发人员团队协作，注重分析和设计等前段开发工作，从而避免了不必要的返工。
其优点是可用于所有类型的软件开发，而对于客户／服务器结构更加有效，可以随时查阅到开发的状态。
1.2.11基于构件的开发模型
基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复
用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过
程。
基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代
的。
基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件
构建，以及测试和发布5个阶段组成，采用这种开发模型的软件过程如图1-13所示。
图1-13采用基于构件的开发模型的软件过程
构件作为重要的软件技术和工具得到极大的发展，这些新技术和工具有
Microsoft
的
DCOM
、Sun
的EJB，以及
OMG
的CORBA
等。
基于构件的开发活动从标识候选构件开
始，通过搜查已有构件库，确认所需要的构件是否已经存在。
如果已经存在，则从构件库中提取出来复用；
否则采用面向对象方法开发它。
之后利用提取出来的构件通过语法和语义检
查后将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。
基于构件的开发方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。
其优点是构件组装模型导致了软件的复用，
提高了软件开发的效率。
构件可由一方定义其规格说明，被另一方实现。
然后供给第三方使
用，构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。
由于采用自定义的组装结构标准，缺乏通用的组装结构标准，因而引入了较大的风险。
可重用性和软件高效性不易协调，需要精干的有经验的分析和开发人员，一般开发人员插不上手。
客户的满意度低，并且由于过分依赖于构件，所以构件库的质量影响着产品质量。
1.2.12基于体系结构的开发模型
基于体系结构的开发模型是以软件体系结构为核心，以基于构件的开发方法为基础。
然
后采用迭代增量方式进行分析和设计，将功能设计空间映射到结构设计空间，再由结构设计
空间映射到系统设计空间的过程。
该开发模型把软件生命周期分为软件定义、需求分析和定
义、体系结构设计、软件系统设计和软件实现5个阶段，采用这种开发模型的软件过程如
图1-14所示。
1-14
采用基于体系结构的开发模型的软件过程
在基于体系结构的开发过程中，首先是基于体系结构的需求获取和分析，将软件体系结
构的概念引入到需求空间，从而为分析阶段到设计阶段的过渡提供更好的支持。
在需求分析
结果的基础上，进行体系结构的设计。
考虑系统的总体结构及系统的构成元素，根据构成元
素的语法和语义在已确定的构件库中寻找匹配的构件。
当不存在符合要求的构件时，则根据
具体情况组装合成新构件或者购买新构件或者根据需要开发新构件而得到满足需求的构件。
在经过语法和语义检查后，将这些构件通过胶合代码组装到一起实现整个软件系统。
在实践
中，整个开发过程呈现多次迭代性。
在传统的软件生命周期中，软件需求分析和定义完成后紧接的是软件系统的设计和实现。
在这种传统的开发方法中，如果软件需求不断变化，最终软件产品可能与初始原型相差很大。
而基
升级会员 