服装行业管理软件维护与演化

运作阶段的关注点在于如何对实现阶段产生的产品、系统或过程进行运行和优化；培训与操作；改进和演变；弃置和运行管理等几个方面。本篇通过对服装行业管理软件维护与演化、软件项目管理和软件过程改进的讨论，实现了CDIO原理与软件工程教学的对应。

服装行业管理软件维护与演化
当系统运转之后，也就是说，当系统在实际生产环境中被用户使用时，系统开发就完成了。系统运转之后，任何针对系统改变所做的工作，都可以被认为是维护。对于软件系统而言，系统的维护与硬件的维护不同。硬件的维护是为了修复或预防损坏及零部件不能正常工作的情况，更换磨损的零部件或者使用技术来延长硬件系统的寿命。然而，对于软件系统，循环结构在循环一万次之后也不会磨损，程序中的符号也不会从语句中脱落，即软 件并不会损坏，不需要定期维修。

所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。软件维护需要根据需求变化或硬件环境的变化来对应用程序进行部分或全部的修改，修改时应充分利用源程序，修改后要填写程序修改登记表，并在程序变更通知书上写明新旧程序的不同之处。其目的是保证软件系统能持续地与用户环境、数据处理操作、政府或其他有关部门的请求取得协调。
而软件演化是在软件系统整个生命周期过程中对系统的更改活动，软件维护可以看成是软件演化的一种特殊形式．

1.1概述
1.1．1软件维护分类
根据引用软件维护的原因，一般情况下服装行业管理软件维护通常可分成改正性维护、适应性维护、完善性维护、预防性维护。
1．改正性维护
由于程序正确性证明尚未得到圆满的解决，软件测试又不可能找出程序中的所有错误，因此，在交付使用的软件中都可能隐藏着某些尚未被发现的错误，而这些错误在某种使用环境下会暴露出来，就需要进行改正性维护。改正性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。这方面的维护工作量约占整个维护工作量的17％～21％。所发现的错误如果不太重要，不影响系统的正常运行，其维护工作就可以随时进行；但是如果错误非常重要，甚至会影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。

2．适应性维护
由于计算机的飞速发展，各类新的机型、新的操作系统、新的软件系统会层出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求，为了使开发出来的软件系统能够适应这种变化，就需要进行适应性维护。适应性维护就是指为了使软件系统适应信息技术变化和管理需求变化而进行的修改。这方面的维护工作量约占整个维护工作量的18％～25％。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。

3．完善性维护
用户在使用软件的过程中，随着业务的发展，常常希望扩充原有软件的功能，或者希望改进原有的功能或性能，以满足用户的新要求，完善性维护就是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。 另外，还包括对处理效率和编写程序的改进。这方面的维护占整个维护工作的50％～60％，是关系到系统并发质量的重要方面。

4．预防性维护
在软件开发完成之后，为了改进应用软件的可靠性和可维护性，适应未来的软硬件环境的变化，也会进行预防性维护。预防性维护中应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。这方面的维护工作量占整个维护工作量的4％左右。

1.1．2软件演化
“变化”是现实世界永恒的主题，只有“变化”才能发展。Lehman认为，现实世界的系统要么变得越来越没有价值，要么进行持续不断的变化以适应环境的变化。软件是对现实世界中问题空间与解空间的具体描述，是客观世界的一种反映。由于环境和技术的变化，软件系统也必须不 断地修改、调整和扩展即不断演化，才能满足用户的需求。因此，构造性和演化性已成为软件的两个基本特征。

由于外部环境和用户需求的不断变化及软件开发技术的不断发展，注定了软件系统只有不断地演化才能适应用户的新需求。如果系统的一个或多个部件随时问经历不断地改进，则称之为演化。演化的目的是为了适应变化环境的需要保持或提高用户的满意度。Lehman等把软件演化定义为软件程序系统在其生命周期中不断维护，不断完善的系统动力学行为。也就是说，软件演化是在软件系统的生命周期内软件维护和软件更新的行为和过程，其目的是为了适应变化的环境的需要和提高用户的满意度。软件演化致力于尽可能限制那些可能被影响的变化本身的性质。在现代软件系统的生命周期内，演化是一项贯穿始终的活动。

软件演化是一个程序不断调节以满足新的软件需求过程。在这一点上讲，软件演化和软件维护在很大程度上具有重叠性，但二者又有本质区别。软件维护是对现有的已交付的软件系统进行修改，使得目标系统能够完成新的功能，或者在新的环境下完成同样的功能，主要是指软件维护期的修改活动。而软件演化则是着眼于软件的整个生命周期，从系统功能行为的角度来观察系统的变化，这种变化是软件的一种向前的发展过程，主要体现在软件功能的不断完善。在软件维护期，通过具体的维护活动可以使系统不断向前演化。因此，软件维护可以看成是软件演化的特定阶段。

1.2软件维护
在现代软件工程中，软件维护的作用越来越重要，对现存软件的维护可能占据开发组织所花费的所有努力的60％以上，而且随着更多的软件被生产出来，这个百分比在持续攀升。在当前视野内，很多软件组织的大量可用资源被花费在旧软件的维护上。

1.2．1软件维护过程模型
软件维护工作的整个过程包括维护申请、维护分类、影响分析、版本规划、变更实施和软件发布等步骤。
在软件系统的维护过程中，也需要建立维护组织。软件维护组织的成员一般包括维护管理员、维护负责人、维护人员、配置管理员等。
维护管理员接收维护申请，并将其转交给维护负责人，他们分析和评估维护申请可能引起的软件变更，并由变更控制管理机构决定是否进行变更，最终由维护人员对软件进行修改。当开发组织外部或内部提出维护申请后，维护人员首先应该判断维护的类型，并评价维护所带来的质量影响和成本开销，决定是否接受该维护请求，并确定维护的优先级。其次，根据所有被接受维护的优先级，统一规划软件的版本，决定维护的先后顺序。最后，维护人员实施相应的维护任务，完成维护工作和新版本的发布。

1.2．2软件维护活动
为了能够有效地对软件维护进行实施和管理．在软件维护中应事先做好组织工作，确定实施维护的机构，明确提出维护申请报告，为每一个维护申请规定标准的处理步骤，并建立维护记录和评价的体制。因此，软件维护活动中应处理好如下方面的内容。

1．软件维护申请报告
在进行软件维护之前应该提出维护申请，并且所有的维护申请都应按照规定的方式提出。如果提出的是适应性维护或完善性维护申请，则用户必须同时提出一份修改说明书，列出所希望的修改。维护申请报告将由维护管理员和系统监督员来研究处理。根据维护申请报告，维护组织应制作相应的软件维护报告，并指明所需修改变动的性质、申请修改的优先级、为满足某个维护申请所需的工作量、预计修改后的状态等信息。

2．软件维护工作流程
软件维护工作必须按照一定的流程来进行，如图12—3所示，不同类型的维护应当实施不同的处理方式。
(1)首先确定用户提出的维护申请类型——提出的维护是适应性维护、完善性维护还是改正性维护，并根据不同的类型执行不同的操作。
(2)对于改正性的维护申请，要先估计错误的严重性。如果问题严重，则必须立即安排维护人员进行问题分析，寻找错误的根源，并给予较高的执行优先级把它放在请求队列的首位。如果问题不严重，则与其他任务统筹考虑，根据轻重缓急再行安排。
(3)对于非改正性的维护请求，则可以分成适应性维护和改善性维护两类。确定维护类型之后，就对它们进行评估，给予不同的优先级，并按优先级排在队列中。但是并不是所有改善性维护请求都予以支持，一般要根据企业本身的策略、可用资源、软件当前及未来发展的趋势等因素来确定是考虑还是拒绝。
(4)在软件维护中，虽然申请的维护类型可能不同，但是都要进行一系列相同的技术工作，比如修改需求说明、修改软件设计、进行设计复审、对源程序做必要修改、实施测试(包括单元测试、集成测试、综合测试)和进行复查等。
在完成每次软件维护任务后，最好进行一次评审，以明确下面的问题：
在维护过程中，哪些资源可以利用，但还没有利用?
设计、程序设计、测试中的哪些方面可以改进?
维护过程中存在哪些障碍?
申请的维护哪些可能会涉及预防性维护?
如果涉及，应该怎样进行处理?

3．维护档案记录
为了便于对软件维护进行有效管理，确保维护中软件产品的质量，需要在维护过程中做好维护档案记录。
维护档案记录的内容包括：维护申请报告的名称、维护人员姓名、维护的类型、程序标志、程序名称、所用的编程语言、源程序语句行数、目标程序代码指令条数、安装的时间、执行中的故障次数、维护中所修改程序的语句行数、修改日期和时间、用于此次维护累计人时数、维护的成本和利润等。

4．软件维护评价
为了评估软件维护的有效程度，确保软件产品的质量和软件维护的不断改进，应建立软件维护的评价体制，并在每次维护完成后按照评价体制对其进行评价。在对软件维护进行评价时，为了能够给以后维护活动的预测和资源的分配提供帮助，需要给出一些定量的指标。此时，可以根
据保存的维护记录，来对维护性能进行度量。
在对软件维护进行评价时，涉及的相关数据包括：
(1)对维护申请的响应时间。
(2)每次维护后，程序运行时的平均出错次数。
(3)各类维护耗费的总人时数。
(4)各类维护的程序平均变动数。
(5)花费在每类维护上的工作量。
(6)各类维护申请的比例等。

1.2．3软件维护技术
在很多拥有大量软件系统的组织机构中，对这些系统进行维护是一个挑战。减少维护工作量的一种方法是从系统开发开始就按质量标准构建系统。但是，除此之外，在软件维护中应用恰当的技术和方法也可以提高软件系统的维护效率。这些技术和方法包括：软件重构、逆向工程、正向工程和再工程等。

1．软件重构
软件重构是为了修改源代码或数据文档，使软件系统适应环境的变化。一般而言，重构不需要修改系统的整体结构，它倾向于关注个别模块的设计细节及局部数据结构。软件重构分为代码重构和文档重构。
代码重构通常是为了生产与源程序具有相同功能、但具有更高质量的设计和代码。而文档重构也称为再分析，主要任务是对既存系统的规模、仆系结构、外部功能、内部算法、复杂度等进行调查分析，以产生系统文档。当对一个系统进行文档重构时，是对源代码进行静态分析，给出 更多的信息，以帮助维护人员理解和引用代码。静态分析仅仅是导出控制路径、变量使用情况、构件调用、构件规模、参数调用等相关信息，不对实际的代码进行任何转换。
文档重构如图12—4所示，包括的信息有：控制流图；变量使用情况表；构件之间的调用关系；
类的层次关系；接口关系表；数据字典信息；测试路径等。

2．逆向工程
逆向工程，有时也叫反向工程，是指为了获得和识别系统的重要组件及其相互关系和行为而分析系统的过程，其目的是从源代码得到软件系 统的规约说明和设计信息，如图12—5所示。
虽然逆向工程与软件重构有相同的地方，但是，逆向工程是指能够从随便设计的、无文档的源程序中获得软件系统的完整设计描述，其范畴远远超出了软件重构。
逆向工程不仅仅是反编译，它涉及从原有系统抽取高层规约，即对既有系统的分析过程，明确系统各组成部分及其相互间的关系，并将系统以一定的形式表现出来，以能够对其进行处理，使软件得以维护。
逆向工程主要可分为再文档和设计恢复两种形式。再文档是指同层抽象的表示和修正；而设计恢复是指使用包括领域知识在内的外部信息来获得关于现有系统的有意义的高层抽象。
逆向工程过程和用于实现该过程的工具的抽象层次可以决定从源代码中抽取出来的设计信息的精密程度。 逆向工程所产生的信息包括：E—R图；数据流和控制流；数据字典；数据引用；测试路径；规约说明等。 逆向工程的关键是在于它从源代码实现中抽取出详细的抽象规约说明的能力。但是，在逆向工程的实施过程中，往往会存在很多的障碍。

3．再工程
软件再工程是软件系统改造的一种形式，它是通过引入现代技术和实践经验，提高遗产系统的能力和可维护性。软件再工程是软件自动化的维护过程，它通过应用新技术和工具来改善软件的维护过程，并改进存在的系统。
再工程被定义为系统地把现有系统转换到一种新的形式，以更低的成本、更快的进度和对客户更少的风险来提高在操作、系统能力、功能、性能或者可演化性等方面的质量。这个定义强调，再工程的焦点是，与进行新的开发相比，它以更高的投资回报来改进系统。 软件再工程同时也是一个工程过程，它将逆向工程、重构和正向工程组合起来，使现存的系统重新构造出新的形式。其中，正向工程是指由抽象的、逻辑性的、不依存代码的设计逐步展开，直至具体代码实现的开发活动，即从需求规格设计到产品初步分布的过程或子过程。

采用一个比较形象的公式可以将其定义为：
软件再工程＝逆向工程+正向工程+重构
因此，软件再工程的处理过程为：首先进行逆向工程，主要包括以实现为基础进行设计恢复，从而重构新的设计，然后再对设计进行设计恢复处理以重构需求，至此，逆向工程过程结束。第二步是从需求到设计再到实现的正向工程过程，它同一般的软件过程相同。另外，在这一过程 中，重构贯穿于每一个环节。

1.2．4软件可维护性
在软件维护中往往会出现一系列的问题，例如，是否可能开发出易于维护的软件系统；在进行软件维护时，能否仍然保持软件的完整性；如何才能够提高软件维护的效率等。这些问题实际上涉及软件的可维护性方面。 软件系统的可维护性可以简单地定义为纠正软件系统出现的缺陷和错误，以满足用户和环境的新要求，并且使得系统能够被理解、修改、校正或改善的难易程度。

对软件可维护性的度量可以从以下几个方面进行。
1．可理解性
可理解性描述了通过阅读源代码和相关文档来了解系统功能及其如何运行情况的难易程度。一个可理解性高的软件系统一般应具备以下的特征：模块化(系统各个模块结构良好、功能完整)，程序代码清晰，编程风格具有一致性(代码风格及设计风格的一致性)，完整性(对输人数据进行完整性检查)，使用有意义的数据名和函数名等。
2．可靠性
可靠性表明一个软件系统在给定的一段时间内正确执行的概率。度量可靠性的方法，主要有两类：第一类是根据程序错误的统计数字来进行可靠性预测。比如用一些可靠性模型，根据程序测试中发现并排除的错误数来预测平均失效间隔时间(MeanTimeToFailure，MTTF)。第二类是当系统的可靠性与复杂性有关时，可以根据程序的复杂性来预测软件的可靠性。
3．可测试性
可测试性表明能够用测试的方法来验证程序正确性的难易程度。软件系统的可测试性取决于系统的可理解性、复杂性、设计合理的测试用例的难易程度等方面的内容。
4．可修改性
可修改性描述了程序能够被正确修改的难易程度。一个可修改的程序应当是可理解的、通用的、简单的、灵活的。通用性是指程序适用于各种功能变化而无需修改。灵活性是指能够容易地对程序进行修改。
5．可移植性
可移植性表明程序从一个运行环境移植到另一个新的运行环境的可能性的大小。一个可移植性好的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的特性。可维护性不但与开发人员采用的分析设计方法和技术熟练程度有关，更与软件项目的管理技术有密切关系。除了与开发方法有关的因素之外，以下因素也会对系统的可维护性产生重要影响：
(1)开发人员是否受过严格的规范化培训。
(2)是否采用标准化的文档资料结构和文档形成机制。
(3)是否采用可维护的程序设计语言。
(4)是否有健全程序的文档。
(5)是否保存规范化的测试资料等。

1.3．1动态特征
1.3软件演化
演化性是系统的普遍特性，系统的演化就是系统的结构、状态、行为、功能等随时间的推移而发生的变化，只要从足够大的时间尺度看，任何系统都处于或快或慢的演化之中，都是演化系统。和其他客观事物一样，软件系统也具有演化性。软件的演化性是指软件系统本身具有的潜在的演化能力，体现了软件系统的动态特征。

随着软件技术的不断发展和对目标软件系统的期望越来越高，具有动态特征的软件越来越引起人们的重视。目标软件系统具有的动态性是由需求的动态性决定的。需求的动态性是指需求本身随时间发生变化，其一，用户不断提出新的要求，而否定过去需求中的一部分内容，难以确 定用户的最终需求；其二，目标软件系统已经运行一段时间后，用户才提出新要求，并且发现正在运行的系统中有很多功能、性能、行为不符合其目前的真实要求。

软件在变更过程中的演化动态特征，具体包括：
(1)软件维护和演化是一个必然的过程。
现实世界在不断变化和发展，当系统的环境发生改变时，新的需求就会浮现。因此为了适应变化的环境需要，继续发挥其应有的作用，软件系统也必须根据需要不断地进行维护和演化。当修改后的系统重新投入使用，又会促使环境的改变，于是演化过程进入循环。
(2)软件的不断修改会导致软件的退化。
随着系统的改变，其结构在衰退。因此，为了能够防止退化的发生．必须增加额外的成本以随着系统的改变，其结构在衰退。因此，为了能够防止退化的发生．必须增加额外的成本以改善软件的结构和质量。这样，在实现必要的系统变更成本上又会增加额外的支出。
(3)软件系统的动态特性是在开发过程的早期建立起来的。
软件的规模限制着自身发生的变更，由于较大的变更会引入更多的缺陷，因而限制了新版本的演化有效程度。这也决定了系统维护过程的总趋势以及系统变更可能次数的极限——系统一旦超过某个最小规模就会变得难以变更。
(4)资源和人员的变化对系统长期演化的影响是不易察觉的。
在大型软件项目开发中，团队成员数量的增加不一定就能提高软件的开发效率。
(5)在软件系统中添加新的功能不可避免地会产生新的缺陷。
在每个版本中增加的功能越多，缺陷将会越多。因此，在一个发布的新版本中有较大的功能增加将意昧着不得不紧跟着一个版本来修补系统新引入的缺陷。相对而言，该版本中的新增加功能较少，而主要是修补这些新产生的软件缺陷。Lehman的结论揭示了软件演化的普遍特性，现实环境决定了软件系统不可避免地发生变更，软件的持续变更又会引入新的缺陷，甚至破坏原有的系统结构，因此决定了软件演化是一个持续不断的动态过程。

1.3．2软件演化分类
软件演化是一个程序不断调节以满足新的软件需求过程。根据不同的特征，软件演化具有不同的分类方法。
根据演化时软件系统是否在运行，可分为静态演化和动态演化。
1)静态演化
静态演化是指软件在停机状态下的演化。其优点是不用考虑运行状态的变迁，同时也没有活动的进行需要处理。然而停止一个应用程序就意味着中断它提供的服务，造成软件暂时失效。
2)动态演化
动态演化是指软件在执行期间的软件演化。其优点是软件不会暂时的失效，有持续可用性的明显优点。但由于涉及状态迁移等问题，比静态演化从技术上更难处理。动态演化是最复杂也是最有实际意义的演化行为。动态演化使得软件在运行过程中，可以根据应用需求和环境变化，动态地进行配置、维护和更新，其表现形式包括系统元素数目的可变性、结构关系的可调整性等。软件的动态演化特性对于适应未来软件发展的开放性、多态性具有重要意义。

根据演化发生的时机，软件演化可分为设计时演化、装载期演化和运行时演化。
1)设计时演化
设计时演化是指在软件编译前，通过修改软件的设计、源代码，重新编译、部署系统来适应变
化。设计时演化是目前在软件开发实践中应用最广泛的演化形式。
2)装载期演化
装载期演化是指在软件编译后、运行前进行的演化，变更发生在运行平台装载代码期间。因为系统尚未开始执行，这类演化不涉及系统状态的维护问题。
3)运行时演化
发生在程序执行过程中的任何时刻，部分代码或者对象中执行期间修改。显而易见，设计时演化是静态演化，运行时演化是一种典型的动态演化，而装载期间的演化既可以被看作静态演化也可以看作是动态演化，取决于它怎样被平台或提供者使用。

1.3．3软件演化过程
软件演化过程是软件演化和软件过程的统一。按ISO／IECl2207标准，软件过程是指软件生命期中的若干活动的集合。活动又称为工作流程，又可细分为子活动或任务。Lehman认为软件演化过程是一个多层次，多循环，多用户的反馈系统。从软件再工程的角度看，软件演化过程是对软件系统进行不断地再工程的过程，是软件系统在其生命周期中不断完善的系统动力学行为。软件演化过程并非是顺序进行的，它是根据一定的环境迭代地、多层次地进行的。在软件演化过程中，不同粒度的活动都会发生，因此它必须更具有灵活性。通过观察和分析，软件演化过程模型中存在以下特征。
1)迭代性
在软件演化过程中，由于软件系统必须不断地进行变更，许多活动要以比传统开发过程更高频率进行重复执行；在整个软件演化过程中存在着大量的呈迭代的活动，许多活动一次又一次地被执行。一次迭代过程类似于传统的瀑布模型，处理相应的活动。每次迭代在其结束时需要进行评估，判断是否提出了新的需求、结果是否达到了预定的要求，然后再进行下一个迭代过程。迭代性是软件演化过程的一个重要特性。

2)并行性
在软件演化过程中，有许多并行的活动，而且这些活动的并行性比传统软件开发过程中的活动的并行性要高。如软件过程的并行、子过程的并行、阶段并行、软件发布版本之间的并行、软件活动之间的并行等。为了提高软件演化过程的效率，必须对软件演化过程进行并行性处理。

3)反馈性
尽管促使软件系统进行演化的原因很复杂，但演化的推动力必然是从对需求的不满产生的。用户的需求和软件系统所处的环境是在不断地变化的，所以当环境变化后就必须作处反馈，以便于软件演化过程的执行。反馈是软件系统演化的基础和依据。

4)多层次性
从不同的角度看，由于粒度的不同，软件演化过程包括不同粒度的过程和活动。为了减少这种复杂性，软件演化过程应被划分为不同的层次，低层模型是对高层模型的细化，而高层模型是对低层模型的抽象。

5)交错性
软件演化过程中活动的执行并不像瀑布模型一样是顺序进行的,软件演化过程是连续性与间断性的统一，其活动的执行是交错着进行的。

1.3．4遗产系统的演化
随着计算机应用的深入和软件工程的发展，服装行业管理软件等管理系统已成为现代社会的最重要的资产之一，越来越多的公司和社会机构依赖于其内部的软件系统来提高竞争力和减少成本。对于那些采用先进的软件工程方法来开发的新系统来说，就可能规划把系统开发和演化很好地计划在一起。
但是，现实中仍然存在大量关键业务的遗留系统。
遗产系统就是所继承的有价值的软件，由于其多年的运行，软件系统可能包含了企业的众多知识，它对公司的业务运作起着重要作用，但它们一般是多年以前使用早期的编程语言和技术编制的，有许多负面特征。遗产系统通常具有以下特点：
(1)遗产系统中蕴含了多年的经验，这是无法取代的。即使知识的表现方式有所不同，但是放弃遗产系统就意味着放弃了积累的知识。
(2)被遗产系统取代的人工系统已不复存在，系统分析只有通过对遗产系统的分析来完成。
(3)用户更愿意接受软件演化，而不是彻底的变革。
(4)遗产系统很大，有成千上万行代码。
(5)遗产系统是在旧的环境中构造的。
因此，遗产系统对那些拥有和操作它们的人来说是一个根本的挑战，这些系统已经开始衰老但仍旧继续提高服务。
由于有些遗产系统对组织的生存至关重要，所以没有理由轻易地让它们完全退出历史舞台或是被新近开发的系统所代替，因此就必须在对它们进行评估的基础上做精心的安排和决策，以期获得最佳的回报。

对于一个大的遗产系统，针对其不同部分和所期望的系统之间的距离，所使用的演化策略是不同的，主要可以有以下4种选择。
1)彻底抛弃这个系统
当系统不能对业务过程产生有效的作用时，一般应该抛弃。如，当一个系统在安装之后，业务过程已经改变，就应该彻底把它抛弃，而不用对它进行维护和演化。

2)继续维护这个系统
当一个系统仍然有存在的必要，系统运行相当平稳，而用户没有提出太多对系统变更的要求时，应该选择这个方案。

3)对系统再工程以改善其可维护性
当系统质量由于经常性的变更已经下降，而且仍然需要做经常性的变更时，可以选择进行再工程。

4)以一个新的系统代替整个或部分系统
当其他因素如新的硬件已经使旧系统无法继续运行，或者有现成的产品可以使用，使新的开发成本非常合理时，就应该选择此方案。对于代替遗留系统，可以对它们采用部分代替，也可以进行完全代替，这要视情况而定。

对遗留系统的评估，必须从业务和系统两个方面进行考虑。
从业务方面来看，必须对该系统的业务价值做出评估。有些遗留系统包含了企业的众多知识，对组织的生存至关重要，业务价值就高；反之则低。从系统方面来看，必须对系统软件、系统支持软件和硬件质量进行评估。对系统方面的评估主要是考虑系统及相应环境的可变更和演化性，以及由此产生的费用的可接受的程度。基于这两方面，可以把遗留系统分为4种类型。

1)低质量、低业务价值
保持这些系统继续运行成本很高、回报率却很低。这类系统是应该抛弃的候选对象。

2)低质量、商业务价值
这些系统承载着组织的重要业务功能，不能随便抛弃。但是，其低质量意味着运行的高成本，因此可以对其进行再工程以提高质量或者以合适的系统替代。

3)高质量、低业务价值
这些系统对组织的贡献很小，但是运行成本也较低，可以对它进行一般的维护，而不需要做太多的变更。

4)高质量、高业务价值
对予这种系统，高业务价值说明其对组织的贡献大，必须保持运行；而高质量说明运行成本低无需对它进行更换。这是组织的最好系统资源，只需对其进行正常维护即可。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com