软件维护的原因，步骤和副作用

众所周知，一个软件交付给客户后，后期的维护问题和维护费用，可能会给公司带来很大的利润增长点的同时，也可能会产生这样那样的问题。郑州知网软件公司今天和大家谈谈郑州软件定制的项目中间遇到的软件维护问题。     
     
    在软件交付之后，软件维护就成为软件变更的一个常规过程。但是软件维护不包括体系结构上的改变，软件维护中的变更仅是修改系统中已有的模块和添加新的模块。

  1．维护的原因

  在运行与维护阶段对软件产品所进行的修改就是维护。维护的原因归结如下。

  (1)、改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷。

  (2)、在软件使用过程中因数据环境发生变化或处理环境发生变化，需要修改软件以适应这种变化。

  (3)、用户和数据处理人员在使用时，经常提出改进现有功能、增加新的功能及改善总体性能的要求，为了满足这些要求，就需要修改软件并把这些要求纳入到软件之中。
 

     2．维护的分类

    按维护性质不同，软件维护可分为改正性维护、适应性维护、完善性维护和预防性维护等。
 

    (1)、软件测试不可能揭露出旧系统中的所有错误，所以在使用过程中程序还将发生错误，诊断和改正这些错误的过程称为改正性维护。

    (2)、新的硬件产品出现，同时新的操作系统或操作系统的新版本也不断推出。外部设备和其他的系统部件也经常更新或升级。另一方面，应用软件的使用寿命一般都在1 0年以上，超过了最初开发这些软件的环境的寿命。为了适应新的变化而进行的修改活动称为适应性维护。

    (3)、一个软件投入运行过程中，用户不断提出增加新功能、修改现有功能以及一般性的改进要求等，为了满足这些要求，需要进行完善性维护，完善性维护活动是软件维护工作的主要部分。
 

    (4)、为了改进软件未来的可维护性或可靠性，或者为了给未来的改进提供更好的基础而对软件进行修改，这类活动通常叫做预防性维护。当然，这类维护比前面三类要少得多。这类维护的特点是采用再造工程技术。

   
      从上面内容可见，软件维护不局限于纠正错误。统计数字表明，完善性维护占全部维护活动的50%-60%，改正性维护占17%～21%，适应性维护占18%～25%，其他维护活动只占4%左右。

     上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。    

    3．维护的问题

    与软件维护有关的绝大多数问题都可归于软件定义和软件开发方法的缺点。与软件维护有关的部分问题如下：

    (1)、理解别人写的程序通常非常困难，特别是一些非结构化程序。如果只有程序代码而没有说明文档，那么困难较大。

    (2)、软件人员经常流动，所以当要求对软件进行维护时，不可能依靠原开发人员提供对软件的解释。

    (3)、没有文档或文档严重不足。认识到软件必须编制文档是第一步，第二步是文档必须是可以理解的，同时还要与源程序代码相一致，否则没有任何价值。

    (4)、绝大多数软件在设计时不考虑以后可能要修改。除非强调模块独立的设计方法，否则软件修改将是困难的，而且还容易引入新的错误。

    (5)、通过多种版本或发行，要追踪软件的演化变得很困难，甚至不可能。而修改又没有足够的文档。

    (6)、追踪软件的建立过程非常困难，或根本做不到。

    (7)、维护被看做是无吸引力的工作，主要是因为维护工作经常遭受挫折。

       ‘

    4．维护步骤

    在软件维护时，必然对源程序进行修改。为了正确、有效地修改，需要经历以下步骤。

    (1)、分析和理解程序。

    经过分析，全面、准确、快速地理解程序是决定维护成败和质量好坏的关键。在这方面，软件的可理解性和文档的质量非常重要。

    ①埋解程序的功能和目标。

    ②掌握程序的结构信息，即从程序中细分出若干结构成分，如程序系统结构、控制结构、数据结构和输入输出结构等。

    ③了解数据流信息，即所涉及的数据来源于何处，在哪里被使用。

    ④了解控制流信息，即执行每条路径的结果。

    ⑤理解程序的操作要求。

    (2)、修改程序。

    对程序的修改，必须事先做出计划，有效地实施修改。

    程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划，而对于需要耗时数月的大修改，就需要计划立案。此外，在编写有关问题和解决方案的大纲时，必须充分地描述修改作业的规格说明。修改计划的内容主要包括以下几项。

    ·规格说明信息：数据修改、处理修改、作业控制语言修改、系统之间接口的修改等。

    ·维护资源：新程序版本、测试数据、所需的软件系统、计算机时间等。

    ·人员：程序员、用户相关人员、技术支持人员、厂家联系人、数据录入员等。

    ·提供：纸面、计算机媒体等。

     针对以上每一项，要说明必要性、从何处着手、是否接受、日期等。通常可采用自顶向下的方法，在理解的基础上，首先研究程序的各个模块、模块的接口及数据库，从全局的观点提出修改计划。其次，依次把要修改的以及那些因修改影响的模块和数据结构分离出来，为此要注意：

    ①识别因修改影响的数据；

    ②识别使用这些数据的程序模块；

    ③对于上面程序模块，按产生数据、修改数据和删除数据进行分类；

    ④识别对这些数据元素的外部控制信息；

    ⑤识别编辑和检查这些数据元素的地方；

    ⑥隔离要修改的部分。

    (3)、设计修改计划。

    详细她分析要修改的模块和数据结构的内部细节，设计修改计划，标明新逻辑及要改动的现有逻辑。

    (4)、向用户提供回避措施。

    用户的某些业务因发生问题而中断，为了不让系统长时间停止运行，需要把问题局部化，在可能的范围内继续开展业务。可以采取的措施有两种。

    ①在问题的原因还未找到时，先就问题的现象提供回避的操作方法，可有以下几种情况：

    意外停机，系统完全不能工作。作为临时的处置，消除特定的数据，插入临时代码，以人工方式运行系统。

    安装的期限到期，而系统有时要延迟变更。例如，税率改变时，继续执行其他处理，同时修补有关的部分，再执行它，或者制作特殊的程序，然后再根据执行结果做修正。

    ·发现错误运行系统，人工查找错误并修正。

    必须正确地了解以现在状态运行系统将给应用系统的业务造成什么样的影响，研究使用现行系统将如何及多大程度地促进应用的业务。

    ②如果弄清了问题的原因，可通过临时修改或改变运行控制以回避在系统运行时产生的问题，如下图所示
 

    (5)、修改代码。

    修改代码以适应变化。在修改时要求：

    ·正确、有效地编写代码。

    ·要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令。

    ·不要删除程序语句，除非完全肯定它是无用的。

    ·不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应自行设置自己的变量。

    ·插入错误检测语句。

    ·在修改过程中做好修改的详细记录，消除变更中任何有害的副作用（波动效应）

    (6)、重新验证程序。

    在将修改后的程序提交用户之前，需要用以下的方法进行充分的确认和测试，以保证整个修改后的程序的正确性。

    ①静态确认。修改软件，伴随着引起新错误的危险。为了能够做出正确的判断，验证修改后的程序至少需要两个人参加。要检查：

    ·修改是否涉及规格说明？修改结果是否符合规格说明？有没有歪曲规格说明7

    ·程序的修改是否足以修正软件中的问题？源程序代码有无逻辑错误等7

    ·修改部分对其他部分有无不良影响？

    ②计算机确认。在充分进行了以上确认的基础上，要用计算机对修改程序进行确认测试。

    ·确认测试顺序。先对修改部分进行测试，然后隔离修改部分，测试程序的未修改
部分，最后再把它们集成起来进行测试。这种测试称为回归测试。

    ·准备标准酌测试用例。

    ·充分利用软件工具帮助重新验证过程。

    ·在重新确认过程中，需邀请用户参加。

    ③维护后的验收。在交付新软件之前，维护主管部门要检验：

    ·全部文档是否完备，并已更新。

    5、软件维护的副作用

        软件修改是一项很危险的工作，对一个复杂的逻辑过程，仅仅做一项微小的改动都可能引入潜在的错误。虽然设计文档化和细致的回归测试有助于排除错误，但是维护仍然会产生副作用。软件维护的副作用是指由于维护或在文档化过程中其他一些不期望的行为引入的错误。副作用大致可分为三类：

    代码副作用

     虽然每次代码修改都可能引入潜在的错误，但是下列修改最易出错：

    (l)修改或删除子程序；

    (2)修改或删除语句标号；

    (3)修改或删除标识符；

    (4)为提高执行效率而做的修改；

    (5)修改文件的open.close操作；

    (6)修改逻辑操作符；

    (7)由设计变动引起的代码修改；

    (8)修改对边界条件的测试。

    代码副作用有时可通过回归测试发现，此时应立即采取补救措施。然而，有时直到交  i付运行后才暴露出来，故对代码进行上述修改应特别慎重o

    数据副作用    

     在维护阶段一一旦修改了数据结构’软件设计与数据可能就不再匹配'错误随即出现数据副作用是指因修改软件的信息结构而带来的不良后果。容易引起数据副作用的傅包括：

    (1)局部或全局常量的再定义；

    (2)记录或文件格式的再定义；

    (3)增减数据或其他复杂数据结构的体积；

    (4)修改全局数据；

    (5)重新初始化控制标志和指针；

    (6)重新排列I／()表或子程序参数表。

    设计文档化有助于限制数据副作用，因为设计文档中详细地描述了数据结构并提一个交叉访问表，把数据和引用它们的模块对应起来。

    文档的副作用

    维护应统一考虑整个软件配置，而不仅是源代码。否则，由于在设计文档和用户手中未能准确反映修改情况而引起文档的副怍用。

   
    对软件的任何修改都应在相应的技术文档中反映出来，如果设计文档不能与软件前的状况对应，则比没有文档更困难。对用户来说，若使用说明中未能反映修改后的况，那么用户在这些问题上必定出错。一次维护完成之后，再次交付软件之前应仔细复整个配置，有效地减少文档副作用。某些维护申请不必修改设计和代码，只需整理用户档便可达到维护的目的。