复工作。因此，经
过少数迭代之后，通常应冻结开发的某些部分，如规格说明，并继续进行后面的开发阶段。
存在的问题留待以后解决，置之不顾，或者通过编程绕过去。这样仓促冻结需求，可能意味 图5A-1：软件生命周期 运行与 维护 集成与 系统测试 实现与 单元测试 系统与 软件设计 需求定义
着系统将难以满足用户的要求。由于使用实现技巧规避了设计问题，这也可能导致不良的系 统结构。
在最后的生命周期阶段（运行与维护），软件投入使用。最初软件需求中存在的错误与
疏漏被发现，程序与设计错误浮现，而且新的功能需要得到确定。因此，为保持有用性，系
36
统必须演变。进行有关更改（软件维护）可能涉及到重复以前的过程阶段。
瀑布模型的优点在于每个阶段都编制文件，而且它与其他的工程过程模型相符合。其主
要问题在于将项目僵硬地划分成不同的阶段。在过程的一个早期阶段，必须定下决心，从而 使得应对客户需求变化很困难。
因此，只有在需求得到很好理解、在系统开发期间不可能发生根本性变化的情况下，才
应使用瀑布模型。然而，瀑布模型体现了在其他工程项目中所使用的过程模型类型。所以，
基于这种方法的软件过程仍然用于软件开发，特别是当有关软件项目是一个较大系统工程项 目的一部分时。 三、演化开发
演化开发基于这样的思想：开发一个初始的实现，让其接受用户评论，并让其经过多个
版本的改进，一直到开发出能够满足需要的系统（图5A-2）。规格说明、开发及验证活动不
是分开进行，而是交叉进行，各项活动之间有快速的信息反馈。 演化开发有两个基本类型：
1、 探索式开发。在这种类型中，过程的目标是与客户协作探索其需
37
求，并交付一个最
终的系统。开发从业已理解的系统部分开始。随着增添客户提出的新特征，系统不 中间 版本 并行活动
图5A-2：演化开发 描述 最终 版本 初始 版本 开发 验证 规格说明 断演变。
2、 抛弃式原型开发。在这种类型中，演化开发过程的目标是理解客户的需求，从而为
系统开发比较好的需求定义。原型集中试验没有很好理解的客户需求。
在生产满足客户眼下需要的系统时，软件开发的演化方法常常比瀑布方法有效。基于演
38
化方法的软件过程的优点是，规格说明可以渐进地开发。随着用户增进对其问题的理解，这
种理解可以反映在软件系统中。然而，从工程和管理的角度来看，演化方法存在两个问题：
1、 过程缺乏可视性。管理员需要定期交付的产品来衡量进度。在快速开发系统的情况
下，编制反映每个系统版本的文件不合算。
2、 系统常常缺乏良好的结构。不断的更改往往会破坏软件的结构。吸收软件更改变得
越来越困难，越来越成本高昂。
对于中小型系统（上至50万行代码），演化方法或许是最佳的开发方法。对于不同小组
开发系统不同部分的大型、复杂、长寿命系统，演化开发存在的问题尤为严重。使用这种方
法难以建立一个稳定的系统体系结构，这使得集成各小组的贡献变得很难。
对于大型系统，建议使用一种混合过程，将瀑布模型和演化开发模型的最佳特征结合起
来。这可能涉及到使用演化方法开发一个抛弃式原型，以解决系统规格说明中存在的不确定
性。然后，可使用一种结构化程度比较高的方法重新实现系统。得到很好理解的系统部分可
39
使用基于瀑布模型的过程进行规格说明和开发。事先难以进行规格说明的其他系统部分，如
用户界面，无例外地应使用探索式编程方法来开发。 四、基于组件的软件工程
大多数软件项目都存在某种程度的软件复用。通常，这是非正式发生的。参加项目的人
知道有现成的设计或编码类似于他们所需的设计或编码。他们寻找这些设计或编码，根据需
要对其进行修改，并将其吸收进他们的系统。对于使用演化方法进行快速系统开发，复用常 常是必要的。
这种非正式复用的发生是不考虑所使用的开发过程的。然而，在过去几年中，出现了一
种软件开发方法，这种方法使用得越来越多，它依靠复用，被称为基于组件的软件工程。
这种面向复用的方法依靠大量的可复用软件组件，以及用于这些组件的某种集成框架。
有时，这些组件本身就是可提供文本格式化或数值计算等特定功能的系统（商用现成系统）。
基于组件的软件工程的类属过程模型如图5A-3所示。
就最初的需求规格说明阶段和验证阶段而言，面向复用过程与其他过程相类似，但它的
40