[理学]第8章-软件维护.ppt

《[理学]第8章-软件维护.ppt》由会员分享，可在线阅读，更多相关《[理学]第8章-软件维护.ppt（41页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第第1章章 软件工程学概述软件工程学概述第第2章章 可行性研究可行性研究第第3章章 需求分析需求分析第第4章章 形式化说明技术形式化说明技术第第5章章 总体设计总体设计第第6章章 详细设计详细设计第第7章章 实现实现第第8章章 维护维护第第9章章 面向对象方法学引论面向对象方法学引论第第10章章 面向对象分析面向对象分析第第11章章 面向对象设计面向对象设计第第12章章 面向对象实现面向对象实现第第13章章 软件项目管理软件项目管理v软件在交付用户使用后，就进入了其生软件在交付用户使用后，就进入了其生命周期的最后一个阶段命周期的最后一个阶段维护，维护维护，维护阶段的基本任务是保证软件在一个相当

2、阶段的基本任务是保证软件在一个相当长的时期能够正常运行。长的时期能够正常运行。v维护也是软件生命周期中持续时间最长维护也是软件生命周期中持续时间最长代价最大的一个阶段。软件工程学的主代价最大的一个阶段。软件工程学的主要目的就是提高软件的可维护性，降低要目的就是提高软件的可维护性，降低维护的代价。维护的代价。教学内容教学内容8.1 软件维护的定义软件维护的定义 8.2 软件维护的特点软件维护的特点8.3 软件维护过程软件维护过程8.4 软件的可维护性软件的可维护性8.5 预防性维护预防性维护8.6 软件再工程过程软件再工程过程v软件维护：指在软件已经交付使用之后，为了软件维护：指在软件已经交付使

3、用之后，为了改正错误或满足新的需要而修改软件的过程。改正错误或满足新的需要而修改软件的过程。v软件维护通常包括软件维护通常包括4 4类活动：改正性维护、适类活动：改正性维护、适应性维护、完善性维护、预防性维护。应性维护、完善性维护、预防性维护。v注意，注意，4 4类维护活动都必须应用于整个软件配类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码同置，维护软件文档和维护软件的可执行代码同样重要。样重要。v改正性维护：改正性维护：为了纠正在使用过程中暴露出来的为了纠正在使用过程中暴露出来的程序错误而进行的维护活动。改正性维护的工作程序错误而进行的维护活动。改正性维护的工作量大约

4、占软件维护总工作量的量大约占软件维护总工作量的17%-21%17%-21%。v适应性维护：适应性维护：为了适应外部环境的变化而进行的为了适应外部环境的变化而进行的维护活动。适应性维护的工作量大约占软件维护维护活动。适应性维护的工作量大约占软件维护总工作量的总工作量的18%-25%18%-25%。v完善性维护：完善性维护：为了根据用户需要改进原有软件而为了根据用户需要改进原有软件而进行的维护活动。完善性维护的工作量大约占软进行的维护活动。完善性维护的工作量大约占软件维护总工作量的件维护总工作量的50%-66%50%-66%。v预防性维护：预防性维护：为了改进软件将来的可维护性和可为了改进软件将来

5、的可维护性和可靠性而进行的维护活动。预防性维护的工作量大靠性而进行的维护活动。预防性维护的工作量大约占软件维护总工作量的约占软件维护总工作量的4%4%。纠错性维护纠错性维护适应性维护适应性维护完善性维护完善性维护预防性维护预防性维护v软件维护的三个特点：软件维护的三个特点：v结构化维护与非结构化维护差别巨大结构化维护与非结构化维护差别巨大v维护的代价高昂维护的代价高昂v维护的问题很多维护的问题很多1. 1. 结构化维护与非结构化维护差别巨大结构化维护与非结构化维护差别巨大维护要求维护要求配置配置评价设计文档评价设计文档计划实施途径计划实施途径修改设计修改设计重新编码重新编码交付使用交付使用评价

6、程序代码评价程序代码复查复查复查复查？修改程序修改程序2. 2. 维护的代价高昂维护的代价高昂v有形代价：软件维护的费用，占软件总预算的有形代价：软件维护的费用，占软件总预算的80%-90%80%-90%v无形代价：无形代价：v可用资源必须供维护任务使用，以致耽误甚至丧失了开发可用资源必须供维护任务使用，以致耽误甚至丧失了开发良机；良机；当看来合理的修改要求不能及时满足时将引起用户不满；当看来合理的修改要求不能及时满足时将引起用户不满；由于维护时的改动，在软件中引入了潜伏的错误，从而降由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量；低了软件的质量；当必须把软件工程师调去从事维

7、护工作时，将在开发过程当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。中造成混乱。v生产率的大幅度下降生产率的大幅度下降v用于维护工作的劳动可以分成生产性活用于维护工作的劳动可以分成生产性活动和非生产性活动。下述表达式给出维动和非生产性活动。下述表达式给出维护工作量的一个模型：护工作量的一个模型：M=P+Kexp(c-d) 其中：其中： lM是维护用的总工作量；是维护用的总工作量；lP是生产性工作量；是生产性工作量；lK是经验常数；是经验常数；lc是复杂程度是复杂程度(非结构化设计和缺少文档非结构化设计和缺少文档都会增加软件的复杂程度都会增加软件的复杂程度)；ld是维护人员对软件

8、的熟悉程度。是维护人员对软件的熟悉程度。3. 3. 维护的问题很多维护的问题很多 与软件维护有关的绝大多数问题，都可归因于与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点，下面列出和软件定义和软件开发的方法有缺点，下面列出和软件维护有关的部分问题：软件维护有关的部分问题：（1） 理解别人写的程序通常非常困难，而且困难程理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。度随着软件配置成分的减少而迅速增加。（2） 需要维护的软件往往没有合格的文档，或者文需要维护的软件往往没有合格的文档，或者文档资料显著不足。容易理解的并且和程序代码完档资料显著不足。

9、容易理解的并且和程序代码完全一致的文档才真正有价值。全一致的文档才真正有价值。（3） 当要求对软件进行维护时，不能指当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。望由开发人员给我们仔细说明软件。（4） 绝大多数软件在设计时没有考虑将绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又的设计方法学，否则修改软件既困难又容易发生差错。容易发生差错。（5） 软件维护不是一项吸引人的工作。软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工形成这种观念很大程度上是因为维护工作经常遭受挫折。作经常

10、遭受挫折。v维护过程本质上是修改和压缩了的软件维护过程本质上是修改和压缩了的软件定义和开发过程：首先必须建立一个维定义和开发过程：首先必须建立一个维护组织，随后必须确定报告和评价的过护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，一个适用于维护活动的记录保管过程，并且规定复审标准。并且规定复审标准。1. 1. 维护组织维护组织2. 2. 维护报告维护报告v软件维护报告应由用户提交的维护要求表和软件组软件维护报告应由用户提交的维护要求表和软件

11、组织制定的软件修改报告两部分构成。织制定的软件修改报告两部分构成。v对于改正性维护，用户需在维护要求表中完整描述对于改正性维护，用户需在维护要求表中完整描述导致出现错误的环境；对于适应性或完善性维护，导致出现错误的环境；对于适应性或完善性维护，则应在维护要求表中提出简短需求说明书。由维护则应在维护要求表中提出简短需求说明书。由维护管理员和系统管理员评价用户提交的维护要求表。管理员和系统管理员评价用户提交的维护要求表。v软件修改报告给出下述信息：软件修改报告给出下述信息：(1) (1) 满足维护要求表中提出的要求所需要的工作量；满足维护要求表中提出的要求所需要的工作量；(2) (2) 维护要求的

12、性质；维护要求的性质；(3) (3) 这项要求的优先次序；这项要求的优先次序；(4) (4) 与修改有关的事后数据。与修改有关的事后数据。3. 3. 维护的事件流维护的事件流4. 4. 保存维护记录保存维护记录需要记录的内容：需要记录的内容：(1) (1) 程序标识；程序标识； (2) (2) 源语句数；源语句数；(3) (3) 机器指令条数；机器指令条数；(4) (4) 使用的程序设计语言；使用的程序设计语言； (5) (5) 程序安装的日期；程序安装的日期； (6) (6) 自从安装以来程序运行的次数；自从安装以来程序运行的次数； (7) (7) 自从安装以来程序失效的次数；自从安装以来程

13、序失效的次数； (8) (8) 程序变动的层次和标识；程序变动的层次和标识；(9) (9) 因程序变动而增加的源语句数；因程序变动而增加的源语句数； (10) (10) 因程序变动而删除的源语句数；因程序变动而删除的源语句数；(11) (11) 每个改动耗费的人时数；每个改动耗费的人时数； (12) (12) 程序改动的日期；程序改动的日期； (13) (13) 软件工程师的名字；软件工程师的名字； (14) (14) 维护要求表的标识；维护要求表的标识； (15) (15) 维护类型；维护类型； (16) (16) 维护开始和完成的日期；维护开始和完成的日期； (17) (17) 累计用于维

14、护的人时数；累计用于维护的人时数； (18) (18) 与完成的维护相联系的纯效益。与完成的维护相联系的纯效益。5. 5. 评价维护活动评价维护活动可以从下述可以从下述7 7个方面定量度量维护工作：个方面定量度量维护工作：(1) (1) 每次程序运行平均失效的次数；每次程序运行平均失效的次数；(2) (2) 用于每一类维护活动的总人时数；用于每一类维护活动的总人时数；(3) (3) 平均每个程序、每种语言、每种维护类型所做平均每个程序、每种语言、每种维护类型所做的程序变动数；的程序变动数；(4) (4) 维护过程中增加或删除一个源语句平均花费的维护过程中增加或删除一个源语句平均花费的人时数；人

15、时数；(5) (5) 维护每种语言平均花费的人时数；维护每种语言平均花费的人时数；(6) (6) 一张维护要求表的平均周转时间；一张维护要求表的平均周转时间；(7) (7) 不同维护类型所占的百分比。不同维护类型所占的百分比。v可以把软件的可维护性定性地定义为：可以把软件的可维护性定性地定义为： 维护人员理解、改正、改动或改进这个维护人员理解、改正、改动或改进这个软件的难易程度。软件的难易程度。v提高可维护性是支配软件工程方法学所提高可维护性是支配软件工程方法学所有步骤的关键目标。有步骤的关键目标。决定软件可维护性的因素主要有下述决定软件可维护性的因素主要有下述5 5个：个：可理解性可理解性v

16、软件可理解性表现为外来读者理解软件的结软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。构、功能、接口和内部处理过程的难易程度。v模块化（模块结构良好，高内聚，松耦合）、模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等，都有文档和良好的高级程序设计语言等等，都有助于提高软件的可理解性。助于提高软件的可理解性。2. 2. 可测试性可测试性v诊断和测试的容易程度取决于软件容易理解诊断和测试的容易程度取决于软件容易理解的程度。的程度。v规范的文档、良好的软件结构、可用的测试

17、规范的文档、良好的软件结构、可用的测试工具和调试工具，以及保存完好的测试报告工具和调试工具，以及保存完好的测试报告对于诊断和测试工作是十分重要的。对于诊断和测试工作是十分重要的。v对于程序模块来说，可以用程序复杂度来度对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，量它的可测试性。模块的环形复杂度越大，全面测试它的难度就越高。全面测试它的难度就越高。3. 3. 可修改性可修改性v软件容易修改的程度与总体设计中讲过的设软件容易修改的程度与总体设计中讲过的设计原理和启发规则直接有关。耦合、内聚、计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系

18、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。等等，都影响软件的可修改性。4. 4. 可移植性可移植性v软件可移植性指的是把程序从一种计算环境软件可移植性指的是把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算（硬件配置和操作系统）转移到另一种计算环境的难易程度。可以把因环境变化而必须环境的难易程度。可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降修改的程序局限在少数程序模块中，从而降低修改的难度。低修改的难度。5. 5. 可重用性可重用性v重用（重用（reusereuse）是指同一事物不做修改或稍）是指同一事物不做修改或稍加改动就在不同环境中多次重复使

19、用。加改动就在不同环境中多次重复使用。v大量使用可重用的软件构件来开发软件，大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性：可以从下述两个方面提高软件的可维护性：v软件中使用的可重用构件越多，软件的可软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少；靠性越高，改正性维护需求越少；软件中使用的可重用构件越多，适应性和软件中使用的可重用构件越多，适应性和完善性维护也就越容易。完善性维护也就越容易。v文档是影响软件可维护性的决定因素。文档是影响软件可维护性的决定因素。v软件系统的文档可以分为用户文档和系统文档两类。软件系统的文档可以分为用户文档和系统文档两类

20、。v用户文档主要描述系统功能和使用方法，并不关心用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；这些功能是怎样实现的；v系统文档描述系统设计、实现和测试等各方面的内系统文档描述系统设计、实现和测试等各方面的内容。容。v总的说来，软件文档应该满足下述要求：总的说来，软件文档应该满足下述要求：(1)(1)必须描述如何使用这个系统；必须描述如何使用这个系统；(2)(2)必须描述怎样安装和管理这个系统；必须描述怎样安装和管理这个系统；(3)(3)必须描述系统需求和设计；必须描述系统需求和设计；(4)(4)必须描述系统的实现和测试，以便使系统成为可维护必须描述系统的实现和测试，以便使系

21、统成为可维护的。的。1. 1. 用户文档用户文档用户文档至少应该包括下述用户文档至少应该包括下述5 5方面的内容：方面的内容：(1)(1)功能描述，说明系统能做什么；功能描述，说明系统能做什么；(2)(2)安装文档，说明怎样安装这个系统以及怎样使系安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；统适应特定的硬件配置；(3)(3)使用手册，简要说明如何着手使用这个系统；使用手册，简要说明如何着手使用这个系统；(4)(4)参考手册，详尽描述用户可以使用的所有系统设参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产施以及它们的使用方法，还应该解释系统

22、可能产生的各种出错信息的含义；生的各种出错信息的含义；(5)(5)操作员指南操作员指南( (如果需要有系统操作员的话如果需要有系统操作员的话) )，说明，说明操作员应该如何处理使用中出现的各种情况。操作员应该如何处理使用中出现的各种情况。2. 2. 系统文档系统文档v所谓系统文档指从问题定义、需求说明所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现到验收测试计划这样一系列和系统实现有关的文档。有关的文档。v描述系统设计、实现和测试的文档对于描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。理解程序和维护程序来说是极端重要的。v可维护性是所有软件都应该具备

23、的基本可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有可特点，必须在开发阶段保证软件具有可理解性、可测试性、可修改性、可移植理解性、可测试性、可修改性、可移植性、可重用性等可维护因素。在软件工性、可重用性等可维护因素。在软件工程过程的每一个阶段都应该考虑并努力程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重前的技术审查和管理复审中，应该着重对可维护性进行复审。对可维护性进行复审。v在需求分析阶段的复审过程中，应该对在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分将来要改

24、进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护植性问题，并且考虑可能影响软件维护的系统界面。的系统界面。v在设计阶段的复审过程中，应该从容易在设计阶段的复审过程中，应该从容易修改、模块化和功能独立的目标出发，修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对评价软件的结构和过程；设计中应该对将来可能修改的部分预作准备。将来可能修改的部分预作准备。v代码复审应该强调编码风格和内部说明代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。在设文档这两个影响可维护性的因素。在设计和编码过程中

25、应该尽量使用可重用的计和编码过程中应该尽量使用可重用的软件构件，如果需要开发新的构件，也软件构件，如果需要开发新的构件，也应该注意提高构件的可重用性。应该注意提高构件的可重用性。v在测试结束时进行最正式的可维护性复在测试结束时进行最正式的可维护性复审，这个复审称为配置复审。配置复审审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完的目的是保证软件配置的所有成分是完整的、一致的和可理解的，而且为了便整的、一致的和可理解的，而且为了便于修改和管理已经编目归档了。于修改和管理已经编目归档了。v在完成了每项维护工作之后，都应该对在完成了每项维护工作之后，都应该对软件维护本身进行仔细认

26、真的复审。软件维护本身进行仔细认真的复审。v维护应该针对整个软件配置，不应该只维护应该针对整个软件配置，不应该只修改源程序代码。修改源程序代码。v每当对数据、软件结构、模块过程或任每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。须立即修改相应的技术文档。v用户通常根据描述软件特点和使用方法用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件，因此对的用户文档来使用、评价软件，因此对软件的可执行部分的修改必须及时反映软件的可执行部分的修改必须及时反映在用户文档中。在用户文档中。v预防性维护方法是由预防性维护方

27、法是由Miller提出来的，他把这种方法提出来的，他把这种方法定义为：定义为：“把今天的方法学应用到昨天的系统上，以把今天的方法学应用到昨天的系统上，以支持明天的需求。支持明天的需求。”v为了修改为了修改“老老”程序以适应用户新的或变更的需求，程序以适应用户新的或变更的需求，通常采用的三种做法：通常采用的三种做法：通过仔细分析程序尽可能多地掌握程序的内部工作细通过仔细分析程序尽可能多地掌握程序的内部工作细节，以便更有效地修改它；节，以便更有效地修改它；在深入理解原有设计的基础上，用软件工程方法重新在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分；设计、重

28、新编码和测试那些需要变更的软件部分；（局部再工程）（局部再工程）以软件工程方法学为指导，对程序全部重新设计、重以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用新编码和测试，为此可以使用CASE工具（逆向工程工具（逆向工程和再工程工具）来帮助理解原有的设计。和再工程工具）来帮助理解原有的设计。（软件再工（软件再工程）程）软件再工程模型软件再工程模型库存目录分析库存目录分析v每个软件组织都应该保存其拥有的所有应用系统的库存目每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息。录。该目录包含关于每个应用系统的基本信息。v对库中每个程序都

29、做逆向工程或再工程是不现实的，通常对库中每个程序都做逆向工程或再工程是不现实的，通常只可能对下述三类程序作预防性维护：只可能对下述三类程序作预防性维护：（1） 预定将使用多年的程序；预定将使用多年的程序；（2） 当前正在成功地使用着的程序；当前正在成功地使用着的程序；（3） 在最近的将来可能要做重大修改或增强的程序。在最近的将来可能要做重大修改或增强的程序。v应该仔细分析库存目录，按照业务重要程度、寿命、当前应该仔细分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用系统排可维护性、预期的修改次数等标准，把库中的应用系统排序，从中选出再工程的候选者，然后明智地

30、分配再工程所序，从中选出再工程的候选者，然后明智地分配再工程所需要的资源。需要的资源。2. 文档重构文档重构v老程序固有的特点是缺乏文档。具体情况不同，老程序固有的特点是缺乏文档。具体情况不同，处理这个问题的方法也不同：处理这个问题的方法也不同：（1）如果一个程序是相对稳定的，正在走向其有用）如果一个程序是相对稳定的，正在走向其有用生命的终点，而且可能不会再经历什么变化，那生命的终点，而且可能不会再经历什么变化，那就让它保持现状。就让它保持现状。（2）只针对系统中当前正在修改的那些部分建立完）只针对系统中当前正在修改的那些部分建立完整文档。整文档。（3）如果某应用系统是完成业务工作的关键，而且

31、）如果某应用系统是完成业务工作的关键，而且必须重构全部文档，则应该设法把文档工作减少必须重构全部文档，则应该设法把文档工作减少到必需的最小量。到必需的最小量。3. 逆向工程逆向工程v软件的逆向工程是分析程序以便在比源软件的逆向工程是分析程序以便在比源代码更高的抽象层次上创建出程序的某代码更高的抽象层次上创建出程序的某种表示的过程，也就是说，逆向工程是种表示的过程，也就是说，逆向工程是一个恢复设计结果的过程。一个恢复设计结果的过程。v逆向工程工具从现存的程序代码中抽取逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计有关数据、体系结构和处理过程的设计信息。信息。4. 代码重构代

32、码重构v代码重构是最常见的再工程活动。代码重构是最常见的再工程活动。v某些老程序具有比较完整、合理的体系结构，但某些老程序具有比较完整、合理的体系结构，但是，个体模块的编码方式却是难于理解、测试和是，个体模块的编码方式却是难于理解、测试和维护的。在这种情况下，可以重构可疑模块的代维护的。在这种情况下，可以重构可疑模块的代码。码。v代码重构步骤：代码重构步骤：用重构工具分析源代码，标注出和结构化程序设用重构工具分析源代码，标注出和结构化程序设计概念相违背的部分；计概念相违背的部分；重构有问题的代码（此项工作可自动进行）；重构有问题的代码（此项工作可自动进行）；复审和测试生成的重构代码并更新代码文

33、档。复审和测试生成的重构代码并更新代码文档。5. 数据重构数据重构v对数据体系结构差的程序很难进行适应性修对数据体系结构差的程序很难进行适应性修改和增强。改和增强。v与代码重构不同，数据重构发生在相当低的与代码重构不同，数据重构发生在相当低的抽象层次上，它是一种全范围的再工程活动。抽象层次上，它是一种全范围的再工程活动。v在大多数情况下，数据重构始于逆向工程活在大多数情况下，数据重构始于逆向工程活动，分解当前使用的数据体系结构，必要时动，分解当前使用的数据体系结构，必要时定义数据模型，标识数据对象和属性，并从定义数据模型，标识数据对象和属性，并从软件质量的角度复审现存的数据结构。软件质量的角度

34、复审现存的数据结构。v当数据结构较差时，应该对数据进行再工程。当数据结构较差时，应该对数据进行再工程。v对数据的修改必然会导致体系结构或代码层对数据的修改必然会导致体系结构或代码层的改变。的改变。6. 正向工程正向工程v正向工程也称为革新或改造，这项活动不仅从现正向工程也称为革新或改造，这项活动不仅从现有程序中恢复设计信息，而且使用该信息去改变有程序中恢复设计信息，而且使用该信息去改变或重构现有系统，以提高其整体质量。或重构现有系统，以提高其整体质量。v正向工程过程应用软件工程的原理、概念、技术正向工程过程应用软件工程的原理、概念、技术和方法来重新开发某个现有的应用系统。和方法来重新开发某个现有的应用系统。v在大多数情况下，被再工程的软件不仅重新实现在大多数情况下，被再工程的软件不仅重新实现现有系统的功能，而且加入了新功能和提高了整现有系统的功能，而且加入了新功能和提高了整体性能。体性能。