2.3 信息系统开发模型

从软件工程的角度来说，信息系统开发模型是指信息系统软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。开发模型能清晰、直观地描述软件开发全过程，明确规定了要完成的主要活动和任务，是信息系统项目管理工作的基础。

典型的开发模型有：瀑布模型、螺旋模型、增量模型、喷泉模型和原型模型等。

2.3.1 瀑布模型

1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到20世纪80年代早期，它一直是唯一被广泛采用的软件开发模型。

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

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接收上一项活动的工作结果，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。采用瀑布模型的信息系统软件开发过程，如图2.2所示。

瀑布模型有以下优点。

（1）为项目提供了按阶段划分的检查点。

（2）当前一阶段完成后，只需要去关注后续阶段。

（3）可在迭代模型中应用瀑布模型。

瀑布模型有以下缺点。

（1）在项目各个阶段之间极少有反馈。

（2）只有在项目生命周期的后期才能看到结果。

（3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

2.3.2 螺旋模型

1988年，Barry Boehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型采用一种周期性的方法来进行系统开发，这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次，如图2.3所示，图中的4个象限代表了以下活动。

（1）制订计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险。

（3）实施工程：实施软件开发和验证。

（4）客户评估：评价开发工作，提出修正建议，制订下一步计划。

沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。例如，在第一圈，确定了初步的目标、方案和限制条件以后，转入右上象限，对风险进行识别和分析。如果风险分析表明，需求具有不确定性，那么在右下的工程象限内，所建的原型会帮助开发人员和客户，考虑其他开发模型，并把需求做进一步修正。客户对工程成果做出评价后，给出修正建议。在此基础上需再次计划，并进行风险分析。在每圈螺线上，风险分析的终点做出是否继续下去的判断。假如风险过大，开发者和用户无法承受，项目有可能终止。多数情况下沿螺线的活动会继续下去，自内向外逐步延伸，最终得到所期望的系统。如果对所开发项目的需求已有了较好的理解或较大的把握，无需开发原型，便可采用普通的瀑布模型。这在螺旋模型中可认为是单圈螺线。与此相反，如果对所开发项目的需求理解较差，需要开发原型，甚至需要不止一个原型的帮助，那就要经历多圈螺线。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。螺旋模型基本做法是在“瀑布模型”的每个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标志一个或多个主要风险，直到所有的主要风险因素都被确定。

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这类系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上影响软件开发过程和软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。

与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力。同时为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。

螺旋模型有以下优点。

（1）设计上的灵活性，可以在项目的各个阶段进行变更。

（2）以小的分段来构建大型系统，使成本计算变得简单容易。

（3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向及项目的可控性。

（4）随着项目推进，客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。

（5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

螺旋模型有以下缺点。

（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时识别风险，则势必造成重大损失。

（2）过多的迭代次数会增加开发成本，延迟提交时间。

2.3.3 增量模型

增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每个线性序列产生软件的一个可发布的“增量”。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。例如，使用增量模型开发字处理软件时，第一个增量构件提供基本的文件管理、编辑和文档生成功能；第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时唯一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。增量模型强调每个增量均发布一个可操作的产品。采用增量模型的软件开发过程，如图2.4所示。

采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品，每次提交一个满足用户需求子集的可运行的产品。整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。每次用户都得到一个满足部分需求的可运行的产品，直到最后一次得到满足全部需求的完整产品。

增量模型描述了为系统需求排定优先级然后分组实现的过程，每个后续版本都为先前版本增加了新功能。在生命周期的早期阶段（计划、分析、设计），需要建立一个考虑整个系统的架构，这个架构应该是具有强的可集成性的，后续的构件方式开发，都是建立在这个架构之上的。剩下的生命周期阶段（编码、测试、交付），来实现每个增量。首先创建的应该是一组核心的功能，或者对于项目至关重要的最高优先级的系统，或者是能够降低风险的系统。随后基于核心功能反复扩展，逐步增加功能以提高性能。

采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。增量模型的缺点是如果增量构件之间存在相交的情况且未很好处理，则必须做全盘系统分析。

2.3.4 喷泉模型

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

该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，所以不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

2.3.5 快速原型模型

快速原型模型又称原型模型。原型本是工程设计中的概念，指的是试制品或样品。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特征，包括系统的功能特征、输入/输出特征和目标约束条件。快速原型是利用原型辅助软件开发的一种思想。经过简单快速分析，快速实现一个系统原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终得到高质量的软件。

由于在需求分析阶段很难得到完全、一致、准确、合理的需求说明，在获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。同时把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展，即先用相对少的成本和较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发出实际的软件系统。

原型模型的开发步骤如下。

1）确认基本需求

在分析员和用户的紧密配合下，快速确定软件系统的基本要求。例如，对系统功能、性能的基本要求，实现这些要求的数据规范、输出报表、统计要求等。这一阶段与生命周期模型的系统分析阶段相似，但这里强调对最基本、最重要的用户需求进行分析和说明，并非对全部需求进行详细分析。

2）开发一个可运行的系统原型

在第一阶段的基础上，开发一个初始的系统原型，这个原型能完成系统的主要功能，具有系统的输入/输出特征，能反映出系统的目标和约束条件。可忽略最终系统在某些细节上的要求，如安全性、健壮性、异常处理等。主要考虑原型系统应充分反映待评价的特性，暂时忽略一切次要的内容。为使开发出来的原型能工作，还必须建立装有实验数据的样本库。为了快速地建立系统原型，并且适应后阶段对原型的频繁修改，需要有高效率的研制工具的支持，例如，采用非常高级的语言实现原型，引入以数据库为核心的开发工具等。

3）试用原型

这是发现问题、消除误解、开发者与系统用户充分协调的一个步骤。开发人员向用户演示原型后，让用户亲自试用，进一步发现问题和不足，通过交流和讨论，确定需要修改变动的部分，这样第一阶段确定的基本需求就得到进一步明晰和精确。它必须通过所有相关人员的检查、评价和测试。

由于原型忽略了许多内容，它集中反映了要评价的特性，外观看起来可能会有些残缺不全。用户要在开发者的指导下试用原型，在试用的过程中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明的描述是否满足用户的愿望。纠正过去交互中的误解和分析中的错误，增补新的要求，并为满足因环境变化或用户的新设想而引起系统需求的变动而提出全面的修改意见。

4）修改原型

根据修改意见对原型进行修改与完善，即舍弃不符合要求的部分，增加所需的功能，满足用户提出的新要求，使原型逐步完善。

在修改原型的过程中会产生各种各样积极的或消极的影响，为了控制这些影响，应当有一个词典，用以定义应用的数据流，以及各个系统成分之间的关系。另外，在用户积极参与的情况下，保留改进前后的两个原型，一旦用户需要时可以退回，而且贯穿地演示两个可供选择的对象，有助于决策。

5）重复3）、4）阶段

修改过的原型给用户再度使用和评价，提出意见，再修改，如此反复，直至达到参与者一致认可，则原型开发的迭代过程可以结束。

6）完善原型与重建系统

针对5）阶段产生的原型，有两种不同的处理方式。

（1）进一步完善原型使其成为最终产品。虽然此时的原型能够正确地反映用户需求，完成系统功能，但有可能还存在一些被忽略的问题，例如，还需加入系统安全可靠性的控制，数据完整性和一致性的控制，通过模块结构和算法的优化来进一步提高系统运行效益，增强系统的容错性与纠错能力，提高系统的可读性和可维护性等，这样原型才能成为真正实用的系统。

（2）重建系统。第一种方式通过完善原型得到最终产品，有开发速度快的优点，但原型模型的增量开发方式使系统结构不理想，可维护性差。对较大的系统采用重建系统方式，把获得原型的过程当做生命周期模型的系统分析阶段，所做的工作只是为系统设计提供经过验证的需求分析，接下来按照生命周期模型继续进行系统设计、编码和测试等开发阶段，重建一个结构更为合理的系统，而将原型丢弃不用。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

同生命周期模型相比较而言，原型模型具有如下特点。

（1）用户参与了系统开发的所有阶段，从而使用户的需求可以及时地、较好地得到满足，系统的实用性强。而在生命周期模型中，用户只介入了需求分析阶段，其他阶段只是开发人员“单干”，因此有可能造成最终系统问题很多，不能投入实际使用。

（2）采用原型模型，用户可以及早接触和使用未来系统的原型，有利于今后的使用和维护，而生命周期模型往往需要经过几个月甚至几年的开发时间，用户才能见到最终系统。

（3）原型模型开发软件，其周期大为缩短，开发费用较少，而生命周期模型的特点是周期长、费用高。

2.3.6 基于构件的开发模型

基于构件的开发模型是利用模块化方法将整个软件系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形成的，开发过程是迭代的。

基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建，以及测试和发布5个阶段组成，采用这种开发模型的软件开发过程，如图2.6所示。

构件作为重要的软件技术和工具得到极大的发展，这些新技术和工具有Microsoft的DCOM、Sun的EJB，以及OMG的CORBA等。基于构件的开发活动从标志候选构件开始，通过搜查已有构件库，确认所需要的构件是否已经存在。如果已经存在，则从构件库中提取出来复用；否则采用面向对象方法开发它。之后利用提取出来的构件通过语法和语义检查后将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。

基于构件的开发方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。其优点是构件组装模型导致了软件的复用，提高了软件开发的效率。构件可由一方定义其规格说明，被另一方实现。然后供给第三方使用，构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。

由于采用自定义的组装结构标准，缺乏通用的组装结构标准，所以引入了较大的风险。可重用性和软件高效性不易协调，需要精干的有经验的分析和开发人员，一般开发人员不介入。客户的满意度低，并且由于过分依赖于构件，所以构件库的质量影响着产品质量。

2.3.7 基于体系结构的开发模型

基于体系结构的开发模型是以软件系统的体系结构为核心，以基于构件的开发方法为基础，然后采用迭代增量方式进行分析和设计，将功能设计空间映射到结构设计空间，再由结构设计空间映射到系统设计空间的过程。该开发模型把软件生命周期分为软件定义、需求分析和定义、体系结构设计、软件系统设计和软件实现5个阶段，采用这种开发模型的软件开发过程，如图2.7所示。

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

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

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

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

2.3.8 RUP

RUP（Rational Unified Process）是Rational公司推出的软件过程模型，它是一个面向对象软件工程的通用业务流程。RUP描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。RUP是软件业界迄今为止商品化最成功的软件过程模型。

RUP可以用二维坐标来描述，如图2.8所示。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要有周期（Cycle）、阶段（Phase）、迭代（Iteration）和里程碑（Milestone）；纵轴以内容组织自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要有活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow）。在时间轴上，RUP划分了4 个阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意，则可以允许项目进入下一个阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了6个核心过程工作流和3个核心支持工作流。核心过程工作流包括：业务建模工作流、需求工作流、分析和设计工作流、实现工作流、测试工作流和发布工作流。核心支持工作流包括：环境工作流、项目管理工作流及配置和变更管理工作流。

初始阶段：定义最终产品视图、业务模型并确定系统范围。

细化阶段：设计及确定系统的体系结构，制订工作计划及资源要求。

构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。

交付阶段：把产品提交给用户使用。

初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。细化阶段结束是第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此时，要检验详细的系统目标和范围、结构的选择及主要风险的解决方案。构造阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行发布。此时，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

9个核心工作流在项目中轮流被使用，在每次迭代中以不同的重点和强度重复。工作流的目的简单描述如下。

业务建模（Business Modeling）：理解待开发系统的组织结构及其商业运作，确保所有参与人员对待开发系统有共同的认识。

需求（Requirements）：定义系统功能及用户界面，使客户知道系统的功能，开发人员知道系统的需求，为项目预算及计划提供基础。

分析和设计（Analysis and Design）：把需求分析的结果转化为实现规格。

实现（Implementation）：定义代码的组织结构、实现代码、单元测试和系统集成。

测试（Test）：校验各自子系统的交互与集成。确保所有的需求被正确实现并在系统发布前发现错误。

发布（Deployment）：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持；制定并实施beta测试。

配置和交更管理（Configuration and Change Management）：跟踪并维护系统所有产品的完整性和一致性。

项目管理（Project Management）：为计划、执行和监控软件开发项目提供可行性的指导；为风险管理提供框架。

环境（Environment）：为组织提供过程管理和工具的支持。

RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程直到成为最终的系统。传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是人们熟悉的瀑布生命周期。这样做的结果是，到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。

一种更灵活、风险更小的方法是多次通过不同的开发工作流，这样可以更好地理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这称为一个迭代生命周期。在工作流中的每次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流和实现工作流和测试工作流。其本身就如同一个小型的瀑布项目（见图2.9）。

RUP有以下优点。

（1）RUP是建立在非常优秀的软件工程原则基础上的，如迭代、需求驱动、基于结构化的过程开发。

（2）RUP提供了几种方法，如每次迭代产生一个工作原型，在每个阶段的结束决定项目是否继续，这些方法提供了对开发过程非常直观的管理。

（3）Rational公司已经并将继续对RUP进行开发，使这个基于HTML的软件工程能够被裁减以适合组织的实际需要。

RUP有以下缺点。

（1）RUP仅仅包含了开发过程。它没有完全覆盖软件过程，从图2.9中能够明显看出，它丢失了维护和技术支持这两个重要的阶段。

（2）RUP不支持组织内的多项目开发，导致组织内的大范围的重用无法实现。

（3）RUP缺少开发商的支持。

（4）RUP在度量管理，重用管理，人员管理和测试方面尚存在缺陷。