软件维护课件

1、第11章 软件维护第1页，共93页。软件维护的3个主要问题：（1）非结构化的维护太多、太难（2）维护费用开销太大（3）维护工作是费力不讨好的事，没有创新，学不到新知识第2页，共93页。要将软件维护做好，就必须做到：开发文档、管理文档、维护文档必须齐全，使所有的维护工作都变为集成化维护工作，也就是提高系统的可维护性的问题。第3页，共93页。在签订软件合同时必须将软件的维护工作范围、内容、期限和费用增加进去，并明确甲乙双方在维护工作中的责任。维护人员在缺陷维护（即程序级）维护和功能维护（即设计级维护）上虽然不能随意地创新，但是可以分析维护前系统的缺陷或毛病，收集并整理用户的意见与建议，从而去策划新

2、版本的蓝图，在新版本的升级上做到有所创新。第4页，共93页。11.1 软件维护的概念所谓软件维护，就是指软件项目或产品在安装、运行并交付给用户使用后，在新版本升级之前的这段时间里，软件厂商向客户提供的服务工作。第5页，共93页。软件维护的分类（1）纠错性维护：产品或项目中存在缺陷或者错误，在测试和验收时未发现，到了使用过程中逐渐暴露出来，需要改正。第6页，共93页。（2）适应性维护：这类维护是为了产品或项目适应变化了的硬件、系统软件的运行环境，如系统升级第7页，共93页。（3）完善性维护：这类维护是为了给软件系统增加一些新的功能，使产品或项目的功能更加完善与合理，又不至于对系统进行伤筋动骨的改

3、造，这类维护占维护活动的大部分。第8页，共93页。（4）预防性维护：这类维护是为了提高产品或项目的可靠性和可维护性，有利于系统的进一步改造或升级换代。第9页，共93页。所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。p299第10页，共93页。软件维护的特点结构化维护的前提是：软件产品或软件项目必须有完善的文档，并且文档与程序代码互相匹配，两者完全一致。在这样的前提下，四大类维护不但都会比较省力，而且维护后可以

4、用原来的测试用例进行回归测试。维护文档只要在原来的文档上加上适当修改，形成修改后的新版本文档即可，该新版本只是一个很小的版本号，不构成大版本的升级。第11页，共93页。反之，若软件产品或软件项目只有程序而没有文档，或文档很不规范，很不齐全，对这样的软件进行维护就不能叫结构化维护，只能叫非结构化维护。第12页，共93页。（1）非结构化维护。如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和（或）设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档

5、，所以不可能进行回归测试（即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试）。非结构化维护需要付出很大代价（浪费精力并且遭受挫折的打击），这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。第13页，共93页。（2）结构化维护。如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查；接下来编写相应的源程序代码，使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。刚才描述的事件构成结

6、构化维护，它是在软件开发的早期应用软件工程方法学的结果。虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。第14页，共93页。维护的代价太大维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。第15页，共93页。与维护有关的问题很多与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，必然会导致在最后阶段出现问题。第16页，共93页。（1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说

7、明文档，则会出现严重的问题。（2）需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。第17页，共93页。（3）当要求对软件进行维护时，不能指望由开发人员给人们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。（4）绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。（5）软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。第18页，共93页。预防性维护对老程序的维护可

8、以选择以下几种方法：（1）反复多次地做修改程序的尝试，与不可见的设计及源代码“顽强战斗”，以实现所要求的修改。（2）通过仔细分析程序尽可能多地掌握程序的内部工作细节，以便更有效地修改它。（3）在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分。（4）以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用CASE工具（逆向工程和再工程工具）来帮助理解原有的设计。第19页，共93页。11.2 软件维护过程软件维护过程又称为软件维护活动。由于在软件的运行过程中，需要不断地进行修改和完善，维护工作量逐年上升。软件维护过程与软件类型、软件开发过程以

9、及人员因素有着密切的关系。第20页，共93页。软件维护过程由一系列变更请求触发。变更请求可能来自系统用户、管理层或者客户。对变更请求经过成本和影响分析评估，一旦变更请求获得批准，就要对系统规划一个新版本，然后实现这个变更。第21页，共93页。第22页，共93页。软件维护的工作量在系统的维护过程中，需要花费很大的工作量。这关系到软件的维护成本问题。与软件维护工作量有关的因素主要有以下几点：（1）系统的大小。（2）程序设计语言。（3）系统的年龄。（4）数据库技术的应用。（5）先进的软件开发技术。（6）其他因素。第23页，共93页。维护工作量的定量分析M=P+Kexp（cd）其中：M维护所用的总工作

10、量；P生产性工作量；K经验常数；c复杂程度（标志设计的好坏及文档完整程度，非结构化设计和缺少文档都会增加软件的复杂程度）；d维护人员对欲维护软件的熟悉程度。上面的模型表明，如果软件的开发途径不好（即没有使用软件工程方法学），而且原来的开发人员不能参加维护工作，那么维护工作量和费用将以指数倍增加。第24页，共93页。软件维护的流程与相关记录建立适当的维护组织通常并不需要建立一个正式的维护机构，在一个维护过程中，每一位参加维护的人员都要明确自己的责任，为了减少维护过程的混乱，建立一种非正式的组织还是有必要的。第25页，共93页。制定维护报告维护要求表是一个外部产生的文件，它是计划维护活动的基础。软

11、件组织内部应该制订出一个软件修改报告，它给出下述信息。（1）满足维护要求表中提出的要求所需要的工作量。（2）维护要求的性质。（3）这项要求的优先次序。（4）与修改有关的背景数据。在拟定进一步的维护计划之前，把软件修改报告提交给修改控制决策机构审查批准。第26页，共93页。软件维护的流程第27页，共93页。在完成软件维护任务之后，进行复审常常是有好处的。一般说来，这种复审试图回答下述问题：（1）在当前处境下设计、编码或测试的哪些方面能用不同方法进行?（2）哪些维护资源是应该有而事实上却没有的?（3）对于这项维护工作什么是主要的（以及次要的）障碍?（4）要求的维护类型中有预防性维护吗?第28页，共

12、93页。保存维护记录对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。第29页，共93页。保存的内容（1） 程序标识。（2） 源程序行数。（3） 机器指令条数。（4） 使用的程序设计语言。（5） 程序安装的日期。（6） 自从安装以来程序运行的次数。（7） 自从安装以来程序失效的次数。（8） 程序变动的层次和标识。（9） 因程序变动而增加的源语句数。（10） 因程序变动而删除的源语句数。（11） 每个改动耗费的人时数。（12） 程序改动的日期

13、。（13） 软件工程师的名字。（14） 维护要求表的标识。（15） 维护类型。（16） 维护开始和完成的日期。（17） 累计用于维护的人时数。（18） 与完成的维护相联系的纯效益。第30页，共93页。维护的副作用软件修改是一项很危险的工作，对一个复杂的逻辑过程，哪怕做一项微小的改动，都可能引入潜在的错误，虽然设计文档化和细致的回归测试有助于排除错误，但是维护仍然会产生副作用。第31页，共93页。（1）代码副作用。在一个地方发现错误后，要修改程序代码，而修改一段程序代码可能波及别处，由此产生新的错误。修改代码将使编码更加混乱，程序结构更不清晰，可读性更差，而且有连锁反应。代码副作用有时通过回归测

14、试即可发现，此时应立即采取补救措施。遗憾的是，有时直到交付运行后才暴露出来，故对代码进行上述修改应特别慎重。第32页，共93页。（2）数据副作用。数据结构是系统的骨架，修改数据结构是对系统伤筋动骨的大手术，在数据冗余与数据不一致方面，可能顾此失彼。当需要修改用户数据时要与用户协商，一旦有疏忽，可能使系统发生意外。数据副作用指因修改软件的信息结构而带来的不良后果。第33页，共93页。（3）文档的副作用。修改文档可能产生的副作用对非结构化维护不适应，对结构化维护要严防程序与文档的不匹配往往会出现这样一种现象，当发现错误后，程序员马上修改程序代码，但没有及时修改文档，这样，便产生程序代码与文档不一致

15、，给以后的技术人员再阅读文档时带来更大的困难。维护应统一考虑整个软件配置，而不仅仅是源代码。第34页，共93页。重新验证程序由于软件维护会产生副作用，所以，经过修改后的软件，在提交给用户之前，应该进行确认和测试，以确保整个系统的正确性。第35页，共93页。（1）静态确认。（2）计算机确认。（3）文档验收。第36页，共93页。软件维护的最新方法软件维护方法的划分p308第37页，共93页。软件维护与软件产品版本升级第38页，共93页。软件维护工作流程（1） 分类整理用户意见。（2） 提出维护申请。（3） 评审、审计、批准维护申请。（4） 修改需求文档。（5） 维护需求文档评审。（6） 修改设计文

16、档。（7） 维护设计文档评审。（8） 修改源程序。（9） 回归测试。（10） 修改软件产品版本号。（11） 交付用户运行。（12） 收集用户反馈意见，准备进行新一轮维护活动，转向流程的第1个步骤。第39页，共93页。UML对软件维护的影响UML确实对软件开发模型与软件生存周期、软件建模方法、软件文档规范和软件人员分工产生重大影响，这种影响将使得分析、设计、实现、维护人员的岗位界线逐渐趋向模糊，因为软件维护实质上是一次更高层次上的开发，它不但可以发现和解决前人的错误，而且可以总结和继承前人的经验与技术。第40页，共93页。CMM/CMMI对软件维护的影响第41页，共93页。11.3 软件的可维护

17、性所谓软件的可维护性，就是维护人员理解、掌握和修改被维护软件的难易程度。可维护性的软件应具备下列4条性质：第42页，共93页。1、可理解性软件模块化、结构化，代码风格化，文档清晰化2、可测试性文档规范化，代码注释化，测试回归化第43页，共93页。3、可修改性模块间低耦合，高内聚，程序块的单入口和单出口，数据局部化，公用模块组件化4、可移植性如用ODBC、ADO来屏蔽对数据库管理系统的依赖，用三层结构来简化对客户浏览层的维护第44页，共93页。决定软件可维护性的因素维护就是在软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性

18、维护，还必须预先进行调试以确定错误的具体位置。第45页，共93页。决定软件可维护性的因素主要有5个：（1）可理解性。可理解性表现为人们理解软件的结构、功能、接口和内部处理过程的难易程度。（2）可靠性。可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。第46页，共93页。（3）可测试性。可测试性表明论证程序正确性的容易程度。一个可测试程序应当是可理解的、可靠的、简单的。诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试

19、方案，以便进行回归测试。第47页，共93页。（4）可修改性。软件可修改性表明程序容易修改的程度。一个可修改的程序，应该具有可理解性、通用性、灵活性等。通用性是指程序适用于各种功能变化而无需修改；灵活性是指能够容易地对程序进行修改。软件容易修改的程度和程序的设计原理和启发规则直接有关。第48页，共93页。（5）可移植性。软件可移植性指的是把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。第49页，共93页。（6）效率。软件的效率表明了一个程序能完成预定的功能，但又不浪费资源的程度。（7）可用性。软件的可用性定义为程序方便、实用、易使用的程度。第50页，共93页。（8）可重

20、用性。所谓重用（reuse）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性：通常，可重用的软件构件在开发时都经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求就越少。很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。第51页，共93页。软件可靠性表明了一个程序按照用户的要求和设计的目标，执行其功能的正确程度。一个可

21、靠的程序应要求是正确的、完整的、一致的和健壮的。现实中，一个程序要达到完全可靠是不实际的，要精确地度量它也不现实。在一般情形下只能通过程序测试去度量程序的可靠性。软件可靠性是指在给定的时间内，在规定的环境条件下系统完成所指定功能的概率。软件可靠性与可用性的定量指标，是指能够以数字概念来描述可靠性的数学表达式中所使用的量。第52页，共93页。提高软件可维护性的方法(1)建立明确的软件质量目标和优先级。(2)使用提高软件质量的工具和技术。(3)进行明确的质量保证审查。(4)选择维护性好的程序设计语言。(5)注重程序的有关文档。第53页，共93页。(6)软件开发时应考虑维护。(7)若干量化的测度。察

22、觉到问题所耗的时间；收集维护工具所用的时间；分析问题所需时间；形成修改说明书所需时间；纠错（或修改）所用时间；局部测试所用时间；整体测试所用时间；维护复审所用时间；完全恢复所用时间。第54页，共93页。软件文档软件文档的意义主要体现在以下几点：（1）软件具有好的和完备的文档容易操作，因为，它能增加软件的可读性和可使用性。不正确的和残缺的文档比没有文档更糟糕。（2）好的文档意味着简洁，风格一致，易于更新，规范化和符合标准。（3）在程序代码的适当位置插入注解，可以提高对程序自身的理解，程序越长、越复杂，这种需要就越迫切。第55页，共93页。历史文档也具有一定的重要性。在软件维护过程中，利用历史文档

23、可以简化维护工作，降低软件维护的难度。例如，通过文档了解软件系统原来的设计思想和技术等，指导维护人员选择适当的方法，制定合理的维护方案，不至于盲目修改程序而危及整个系统的完整性。历史文档主要有：第56页，共93页。（1）系统开发日志。（2）错误记载。（3）系统维护日志。第57页，共93页。软件文档的要求（1）必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用。（2）必须描述怎样安装和管理这个系统。（3）必须描述系统需求和设计。（4）必须描述系统的实现和测试，以便使系统成为可维护的。第58页，共93页。软件文档的分类软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述

24、系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。第59页，共93页。用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。第60页，共93页。用户文档至少应该包括下述5方面的内容：（1）功能描述，说明系统能做什么。（2）安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。（3）使用手册，简要说明如何着手使用这个系统（应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动）。（4）参考手册，详尽描述用户可以使用的所有系统设施以

25、及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）。（5）操作员指南（如果需要有系统操作员的话），说明操作员应该如何处理使用中出现的各种情况。第61页，共93页。所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。第62页，共93页。维护文档和维护管理文档对于结构化维护来说，软件维护文档就是对原来已有的分析文档、

26、设计文档、实现文档、测试文档、用户指南进行修改，形成新的开发文档。新的开发文档的组织方式有两种格式：格式1：在先保存好原有的开发文档之后，直接在原来已有的文档上面修改，修改后形成新的小版本号文档，即在原来版本号中小圆点的右一位或右二位上加1。格式2：不直接在原来已有的文档上面修改，而是将修改的内容单独作为一个附录，放在被修改文档的最后面，形成一份新的小版本号文档，即在原来版本号中小圆点的右一位或右两位上加1。第63页，共93页。软件维护管理文档有：（1） 用户意见反馈表。（2） 用户意见分类整理表。（3） 维护申请单。（4） 维护文档评审报告。（5） 产品缺陷统计表。（6） 功能扩充统计表。（

27、7） 未答复问题汇总表。（8） 未验证问题汇总表。（9） 已修改问题汇总表。（10） 已验证问题汇总表。（11） 维护费用统计表。第64页，共93页。可维护性复审可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有前面提到的那些可维护因素。在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。第65页，共93页。（1）在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。第66页，共93页。（2）在正式的和非正式

28、的设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预做准备。（3）代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。第67页，共93页。（4）在设计和编码过程中应该尽量使用可重用的软件构件，如果需要开发新的构件，也应该注意提高构件的可重用性。每个测试步骤都可以暗示在软件正式交付使用前，程序中可能需要做预防性维护的部分。在测试结束时进行最正式的可维护性复审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的，而且为了便于修改和管理已经编目归档了。第68页，共93页。（5）在完成了每项维

29、护工作之后，都应该对软件维护本身进行仔细认真的复审。维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果。第69页，共93页。11.4 软件再工程软件再工程（再生）是软件工程中的一类重新构建活动，它能够增进我们对软件的理解，提高软件自身的可维护性、重用性和演化性等。软件再工程就是指重新实现系统的功能，并且加入新的功能或性能，以提高软件的整体质量。第70页，共93页。再工程与新软件建造之间的重要差别在软件的开发起点上。如果我们把传统的新软件开发称为正向工程，那么，它开始于系统描述（包括设计和实现）。而再工程开始于已有的系统，不

30、再从系统描述开始，开发过程基于对旧系统的理解和转换，把旧系统作为目标系统的描述。第71页，共93页。软件再工程活动典型的软件再工程过程模型包含了多项活动。在某些情况下这些活动以线性顺序发生，但也并非总是这样，例如，为了理解某个程序的内部工作原理，可能在文档重构开始之前必须先进行逆向工程。第72页，共93页。一、库存目录分析每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息（例如，应用系统的名字，最初构建它的日期，已做过的实质性修改次数，过去18个月报告的错误，用户数量，安装它的机器数量，它的复杂程度，文档质量，整体可维护性等级，预期寿命，在未来36个月内

31、的预期修改次数，业务重要程度等）。第73页，共93页。下述3类程序有可能成为预防性维护的对象：（1）预定将使用多年的程序。（2）当前正在成功地使用着的程序。（3）在最近的将来可能要做重大修改或增强的程序。第74页，共93页。二、文档重构（1）建立文档非常耗费时间，不可能为数百个程序都重新建立文档。如果一个程序是相对稳定的，正在走向其有用生命的终点，而且可能不会再经历什么变化，那么，让它保持现状是一个明智的选择。第75页，共93页。（2）为了便于今后的维护，必须更新文档，但是由于资源有限，应采用“使用时建文档”的方法，也就是说，不是一下子把某应用系统的文档全部都重建起来，而是只针对系统中当前正在

32、修改的那些部分建立完整文档。随着时间流逝，将得到一组有用的和相关的文档。（3）如果某应用系统是完成业务工作的关键，而且必须重构全部文档，则仍然应该设法把文档工作减少到必需的最小量。第76页，共93页。三、逆向工程软件的逆向工程是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程，也就是说，逆向工程是一个恢复设计结果的过程，逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计信息。第77页，共93页。四、代码重构为了完成代码重构活动，首先，用重构工具分析源代码，标注出和结构化程序设计概念相违背的部分。然后，重构有问题的代码（此项工作可自动进行）。最后，复审和测试生成

33、的重构代码（以保证没有引入异常）并更新代码文档。第78页，共93页。通常，重构并不修改整体的程序体系结构，它仅关注个体模块的设计细节以及在模块中定义的局部数据结构。如果重构扩展到模块边界之外并涉及软件体系结构，则重构变成了正向工程。第79页，共93页。五、数据重构与代码重构不同，数据重构发生在相当低的抽象层次上，它是一种全范围的再工程活动。在大多数情况下，数据重构始于逆向工程活动，分解当前使用的数据体系结构，必要时定义数据模型，标识数据对象和属性，并从软件质量的角度复审现存的数据结构。第80页，共93页。六、正向工程正向工程也称为革新或改造，这项活动不仅从现有程序中恢复设计信息，而且使用该信息

34、去改变或重构现有系统，以提高其整体质量。正向工程过程应用软件工程的原理、概念、技术和方法来重新开发某个现有的应用系统。在大多数情况下，被再工程的软件不仅重新实现现有系统的功能，而且加入了新功能并提高了整体性能。第81页，共93页。软件再工程的风险（1）过程风险。（2）人员风险。（3）应用问题风险。（4）技术风险。（5）工具风险。（6）策略风险。第82页，共93页。系统体系结构的变更p319集中式主机型系统被再工程为分布式客户机/服务器系统具有以下特征：（1） 应用功能迁移到每一个客户机。（2） 一些特殊的功能可以保留在服务器。（3） 新的GUI界面被实现在客户端。（4） 数据库功能分配给服务器。（5） 新的通信、安全、归档和控制需求必须在客户端和服务器端同时建立。第83页，共93页。软件再工程的相关技术设计恢复是指借助于工具从已有程序中抽象出有关数据设计、体系结构设计、过程设计等的信息，但它们不一定是原设计。重构是指在同一个抽象级别上转换系统描述形式。重构工程也称修复或改造工程，它是在逆向工程所获得的信息的基础上修改或重构原来的系统，同时，可能加上一些新的功能和性能，以提高系统的综