199.维护

第8章  维护

基本任务：

    是保证软件在一个至关长的时期可以正常运行。

 

    软件维护须要的工做量很大，60%以上的人力用于维护已有的软件，随着投入使用的软件数量增多和使用寿命延长，这个百分比还在持续上升。最终致使软件开发组织没有余力开发新的软件。

 

软件工程的目的：

    要提升软件的可维护性，减小软件维护所须要的工做量，下降软件系统的总成本。

 

8.1  软件维护的定义

软件维护：

    在软件已经交付使用以后，为了改正错误或知足新的须要而修改软件的过程。

    能够经过如下4项活动，具体地定义软件维护。

 

•四种维护类型：

 改正性维护

 适应性维护

 完善性维护

  预防性维护

 

1.改正性维护

    在软件交付使用后，因开发时测试的不完全、不彻底，必然会有部分隐藏的错误遗留到运行阶段。

    这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。

    为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程。

 

2.适应性维护

  在使用过程当中，外部环境、数据环境可能发生变化。

 外部环境（新的硬、软件配置）

 数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）

适应性维护：为使软件适应这种变化，而去修改软件的过程。

 

3.完善性维护

•在软件的使用过程当中，用户每每会对软件提出新的功能与性能要求。

•完善性维护：

    为了知足上述要求，须要修改或再开发软件而进行的完善性的维护活动。以扩充软件功能、加强软件性能、改进加工效率、提升软件的可维护性。

•完善性维护不必定是救火式的紧急维修，能够是有计划、有预谋的一种再开发活动。

 

4.预防性维护

•预防性维护：

   为了提升软件的可维护性、可靠性等，为之后进一步改进软件打下良好基础而修改软件的维护活动。

•预防性维护的定义：

   采用先进的软件工程方法对须要维护的软件或软件中的某一部分（从新）进行设计、编制和测试的过程。

 

国外的统计数字代表：

完善性维护占所有维护活动的50%～66%，

改正性维护占17%～21%，

适应性维护占18%～25%，

其余维护活动只占4%左右。

 

完善性维护占了几乎一半的工做量。

可见：

大部分维护工做是改变和增强软件，不是纠错。

 

8.2  软件维护的特色 

 8.2.1  结构化维护与非结构化维护差异巨大

1. 非结构化维护

    若是软件配置的唯一成分是程序代码，

•那么维护活动从艰苦地评价程序代码开始。

•没有设计文档及测试文档。

    非结构化维护须要付出很大代价，这种维护方式是没有使用良好的方法学开发出来的软件的必然结果。

 

2. 结构化维护

    若是有一个完整的软件配置存在，

•那么维护工做从评价设计文档开始；

•估量要求的改动将带来的影响，而且计划实施途径。

•而后修改设计而且对所作的修改进行仔细复查。

•编写相应的源程序代码；

•使用在测试说明书中包含的信息进行回归测试；

•把修改后的软件再次交付使用。

 

8.2.2  维护的代价高昂

•软件维护活动所花费的工做占整个生存期工做量的70%以上。

  在漫长的软件运行过程当中须要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改须要花费不少精力和时间，并且有时会引入新的错误。

•维护费用是软件维护的最明显的代价，还有一些无形的代价。

无形的代价还有：

•可用的资源必须供维护任务使用，以至耽误甚至丧失了开发的良机。

•改错或修改的不及时，引发的用户不满；

•因为维护时的改动，在软件中引入了潜伏的错误，从而下降了软件的质量；

•把软件工程师调去从事维护工做，在开发过程当中形成的混乱。

•生产率的大幅度降低，尤为在维护旧程序时经常遇到。

 

维护工做量的一个模型：M = P + K × exp(c-d)

其中：

• M是维护用的总工做量，

• P是生产性工做量（分析等必要的过程） ，

• K是经验常数，

• c是复杂程度(非结构化设计和缺乏文档都会增长软件的复杂程度)，

• d是维护人员对软件的熟悉程度。

模型代表：

    若是软件的开发途径很差(没有使用软件工程方法学)，并且原来的开发人员不能参加维护工做，那么维护工做量和费用将指数地增长。

 

8.2.3  维护的问题不少

    存在于没采用软件工程思想开发出来的软件中：

（1） 仅有程序代码没有说明文档；。

（2） 缺乏容易理解的而且和程序代码彻底一致的文档；

（3） 不能期望由开发人员给咱们仔细说明软件。因为维护阶段持续的时间很长，写程序的人已经不在了。

（4） 绝大多数软件在设计时没有考虑未来的修改。没有使用模块独立的原理去的设计，使修改软件既困难又容易发生差错。

   因此，应采用软件工程思想来开发软件

 

8.3  软件维护过程

• 先创建一个维护组织；

• 肯定报告和评价的过程；

• 为每一个维护要求规定一个标准化的事件序列；

• 创建一个适用于维护活动的记录保管过程；

• 规定复审标准。

 

1. 维护组织

对于每一个维护要求：

•经过维护管理员转交给相应的系统管理员去评价。

    系统管理员对维护任务作出评价以后，

•由变化受权人决定应该进行的活动。

 

图8.1描绘了上述组织方式。

目的：在维护活动开始以前就明确维护责任。

 

图8.1 维护组织

 

2. 维护报告

• 应该用标准化的格式表达全部软件维护要求。

• 软件维护人员一般给用户提供空白的维护要求表——有时称为软件问题报告表。

    这个表格由要求维护活动的用户填写。

    由维护管理员和系统管理员评价用户提交的维护要求表。

 

3. 维护的事件流

图8.2描绘了由一项维护要求而引出的一串事件。

•首先应该肯定要求进行的维护的类型。

•改正性维护要求：

    估量错误的严重程度；

    是一个严重的错误，在系统管理员的指导下分派人员，当即开始问题分析过程；

    错误并不严重，与其余的软件开发任务一块儿统筹安排。

•适应性维护和完善性维护要求：

    应该肯定每一个维护要求的优先次序；

    安排要求的工做时间；

    若是优先次序很是高，可能当即开始维护工做。

 

软件维护工做流程

 

4. 保存维护记录

①程序标识；②源语句数； ③机器指令条数；

④使用的程序设计语言；⑤程序安装的日期；

⑥自从安装以来程序运行的次数；

⑦自从安装以来程序失效的次数；

⑧程序变更的层次和标识；

⑨因程序变更而增长的源语句数；

    因程序变更而删除的源语句数； 每一个改动耗费的人时数； 程序改动的日期； 软件工程师的名字； 维护要求表的标识； 维护类型； 维护开始和完成的日期； 累计用于维护的人时数； 与完成的维护相联系的纯效益。

 

5. 评价维护活动

从下述7个方面度量维护工做：

(1) 每次程序运行平均失效的次数；

(2) 用于每一类维护活动的总人时数；

(3) 平均每一个程序、每种语言、每种维护类型所作的程序变更数；

(4) 维护过程当中增长或删除一个源语句平均花费的人时数；

(5) 维护每种语言平均花费的人时数；

(6) 一张维护要求表的平均周转时间；

(7) 不一样维护类型所占的百分比。

    由此作出关于开发技术、语言选择、维护工做量规划、资源分配等方面的决定。

 

8.4  软件的可维护性

    定义： 维护人员理解、改正、改动或改进这个软件的难易程度。

    提升可维护性是软件开发阶段各个时期的关键目标。

8.4.1  决定软件可维护性的因素

维护：就是在软件交付使用后进行的修改。

•修改以前必须理解待修改的对象，

•修改以后应该进行必要的测试，以保证所作的修改是正确的。

•若是是改正性维护，还必须预先进行调试以肯定错误的具体位置。

 

所以，决定软件可维护性的因素主要有下述5个：

   可理解性，可测试性，可修改性，可移植性，

   可重用性

 

1. 可理解性

•可理解性：外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。

•影响因素：

    模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等。

 

2. 可测试性

•可测试性：论证程序正确性的容易程度。

•模块的环形复杂度可度量它的可测试性。

    模块的环形复杂度越大，可执行的路径就越多，全面测试它的难度就越高。

•影响因素：

良好的文档，软件结构、测试工具和调试工具，之前测试时设计的测试过程。

 

3. 可修改性

可修改性：软件容易修改的程度。

影响因素：耦合、内聚、信息隐藏、局部化、控制域与做用域的关系等等。

 

4. 可移植性

可移植性：把程序从一种计算环境（硬件配置和操做系统）转移到另外一种计算环境的难易程度。

对策：

    把与硬件、操做系统及其余外部设备有关的程序代码集中放到特定的程序模块中，受环境变化影响的仅有少数程序模块，从而下降修改的难度。

 

5. 可重用性

重用（reuse）：同一事物不作修改或稍加改动就在不一样环境中屡次重复使用。

使用可重用的构件来开发软件，能够提升软件的可维护性：

• 软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少。

• 很容易修改可重用的软件构件使之再次应用在新环境中，所以，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。

 

8.4.2  文档

文档：是影响软件可维护性的决定因素。

    大型软件系统在长期的使用过程当中必然会经受屡次修改，因此文档比程序代码更重要。

文档分类：

•系统文档：描述系统设计、实现和测试等一系列和系统实现有关的文档。

•用户文档：描述系统功能和使用方法，并不关心这些功能怎样实现。包括：

功能描述；安装文档；使用手册；参考手册；操做员指南。

 

用户文档应包括的5方面内容：

(1) 功能描述，说明系统能作什么；

(2) 安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；

(3) 使用手册，经过丰富例子说明怎样使用经常使用的系统功能，及用户操做错误时怎样恢复和从新启动；

(4) 参考手册，详尽描述用户可使用的全部系统设施及使用方法，解释系统可能产生的各类出错信息的含义；

(5) 操做员指南(若是须要的话)，说明操做员应该如何处理使用中出现的各类状况。

 

8.4.3  可维护性复审

•在软件工程过程的每个阶段都应该努力提升软件的可维护性，在每一个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。

    从需求分析到设计与编码等各阶段。

•在完成了每项维护工做以后，都应该对软件维护自己进行仔细认真的复审。

•维护应该针对整个软件配置，不该该只修改源程序代码。

 

8.5  预防性维护

产生背景:

存在这样一些程序：

•体系结构和数据结构都不好，

•文档不全甚至彻底没有文档，

•对曾经作过的修改也没有完整的记录。

•但仍然在为用户服务。

怎样知足用户对这类程序的维护要求呢？

 

有如下几种作法可供选择：

（1） 反复屡次地作修改程序的尝试，与不可见的设计及源代码“顽强战斗”，以实现所要求的修改；

    该作法很盲目，一般人们采用后3种作法。

（2） 经过仔细分析程序尽量多地掌握程序的内部工做细节，以便更有效地修改它；

（3） 在深刻理解原有设计的基础上，用软件工程方法从新设计、从新编码和测试那些须要变动的软件部分；

（4） 以软件工程方法学为指导，对程序所有从新设计、从新编码和测试，为此可使用CASE工具（逆向工程和再工程工具）来帮助理解原有的设计。

 

 

•由Miller提出的。

•定义：“把今天的方法学应用到昨天的系统上，以支持明天的需求。”

依据：

（1） 维护一行源代码的代价多是最初开发该行源代码代价的14~40倍；

（2） 从新设计软件体系结构（程序及数据结构）时使用了现代设计概念，它对未来的维护可能有很大的帮助；

 

依据：

（3） 因为现有的程序版本可做为软件原型使用，开发生产率可大大高于平均水平；

（4） 用户具备较多使用该软件的经验，所以，可以很容易地搞清新的变动需求和变动的范围；

（5） 利用逆向工程和再工程的工具，可使一部分工做自动化；

（6） 在完成预防性维护的过程当中能够创建起完整的软件配置。

 

8.6  软件再工程过程

过程模型如图8.3所示，定义了6类活动。

    再工程范型是一个循环模型。每一个活动均可能被重复，过程能够在完成任意一个活动以后终止。

 

图8.3 软件再工程过程模型

 

下面简要地介绍该模型所定义的6类活动。

1. 库存目录分析

•每一个软件组织都应该保存其拥有的全部应用系统的库存目录。

•该目录包含关于每一个应用系统的基本信息（例如，应用系统的名字，最初构建它的日期，已作过的实质性修改次数，过去18个月报告的错误，用户数量，安装它的机器数量，它的复杂程度，文档质量，总体可维护性等级，预期寿命，在将来36个月内的预期修改次数，业务重要程度等）。

•库存目录分析：分析哪些须要进行再工程过程。

有3类程序：

（1） 预约将使用多年的程序；

（2） 当前正在成功地使用着的程序；

（3） 在最近的未来可能要作重大修改或加强的程序。

 

2. 文档重构

老程序固有的特色是缺少文档。处理方法：

（1） 若是一个程序是相对稳定的，正在走向终点，保持现状，不建文档。

（2） 只针对系统中当前正在修改的那些部分创建完整文档。随着时间流逝，将获得一组有用的和相关的文档。

（3） 若是某应用系统是完成业务工做的关键，并且必须重构所有文档，也设法把文档工做减小到必需的最小量。

 

3. 逆向工程

•软件的逆向工程：是分析程序以便在比源代码更高的抽象层次上建立出程序的某种表示的过程；

•逆向工程是一个恢复设计结果的过程；

•逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计信息。

 

4. 代码重构

•代码重构是最多见的再工程活动。

•某些老程序具备比较完整、合理的体系结构，可是，个体模块的编码方式倒是难于理解、测试和维护的，可进行代码重构。

•重构过程：分析源代码→标注需重构部分→重构→复审、测试→更新文档。

•重构并不修改总体的程序体系结构，它仅关注个体模块的设计细节以及在模块中定义的局部数据结构。

•若是重构扩展到模块边界以外，并涉及软件体系结构，则重构变成了正向工程。

 

5. 数据重构

•对数据体系结构差的程序很难进行适应性修改和加强；

•数据体系结构比源代码自己对程序的长期生存力有更大影响；

•因为数据体系结构对程序体系结构及算法有很大影响，对数据的修改必然会致使体系结构或代码层的改变。

•当数据结构较差时，应该对数据进行再工程。

 

6. 正向工程

•正向工程也称为革新或改造；

•不只从现有程序中恢复设计信息，并且使用该信息去改变或重构现有系统，以提升其总体质量。

•被再工程的软件不只从新实现现有系统的功能，并且加入了新功能和提升了总体性能。

 

8.7  小结

维护是软件生命周期的最后一个阶段，也是持续时间最长代价最大的一个阶段。

软件维护一般包括4类活动：

为了纠正在使用过程当中暴露出来的错误而进行的改正性维护；

为了适应外部环境的变化而进行的适应性维护；

为了改进原有的软件而进行的完善性维护；

以及为了改进未来的可维护性和可靠性而进行的预防性维护。

 

软件的可理解性、可测试性、可修改性、可移植性和可重用性，是决定软件可维护性的基本因素。

软件重用技术能从根本上提升软件可维护性。

软件生命周期每一个阶段的工做都和软件可维护性有密切关系。所以，在软件生命周期的每一个阶段都必须充分考虑维护问题，而且为软件维护预作准备。

文档是影响软件可维护性的决定因素，甚至比程序代码更重要。文档必须和程序代码同时维护。

虽然因为维护资源有限，目前预防性维护在所有维护活动中仅占很小比例，但在条件具有时应该主动地进行预防性维护。

预防性维护实质上是软件再工程。