一、系统运行

系统切换后可开始投入运行，系统运行包括系统的日常操作、维护等。任何一个系统都不是一开始就很好的，总是经过多重的开发、运行、再开发、再运行的循环不断上升的。开发的思想只有在运行中才能得到检验，而运行中不断积累问题是新的开发思想的源泉。

1.运行的组织

目前我国不够重视运行，运行组织不健全，运行组织级别不够高。随着信息作用的增加，现在国外企业中信息系统的地位越来越高，信息系统的组织也越来越健全和庞大。从信息系统在企业中的地位看，有以下几种形式：

(1)为企业的某业务部门所有

这种运行组织方式是一种古老的组织方式，信息管理部门为企业的某个业务单位所有。它使得信息不能成为全企业的资源，只能为其它单位提供计算能力，地位太低。

(2)与企业的部门平行

信息资源可为全企业共享，各单位用机权力相等，但信息处理支持决策的能力较弱。

(3)作为企业的参谋中心

这种组织方式有利于信息共享和支持决策，但容易造成脱离群众、服务不好的现象。现在的发展趋势是集散系统，既有全公司信息中心又在使用计算机较多的部门配置微机。它实际是前两种方式的结合，但一定要加强信息资源管理，否则容易造成分散化。

2.系统运行管理

系统运行管理制度是系统管理的一个重要内容。它是确保系统安装预定目标运行并充分发挥其效益的一切必要条件、运行机制和保障措施。通常它应该包括：

（1）系统运行的组织机构

它包括各类人员的构成、各自职责、主要任务和管理内部组织结构。

（2）基础数据管理

它包括对数据收集和统计渠道的管理、计量手段和计量方法的管理、原始数据管理、系统内部各种运行文件、历史文件（包括数据库文件）的归档管理等。

（3）运行制度管理

它包括系统操作规程、系统安全保密制度、系统修改规程、系统定期维护制度以及系统运行状态记录和日志归档等等。

（4）系统运行结果分析

它就是要通过系统运行结果分析得到某种能够反映企业组织经营生产方面发展趋势的信息，提高管理部门指导企业的经营生产的能力。

二、系统维护

1．系统维护的定义

系统维护是指在管理信息系统交付使用后，为了改正错误或满足新的需要而修改系统的过程。

管理信息系统是一个复杂的人机系统，系统内外环境，以及各种人为的、机器的因素都不断地在变化着。为了使系统能够适应这种变化，充分发挥软件的作用，产生良好的社会效益和经济效益，就要进行系统维护的工作。

另外，大中型软件产品的开发周期一般为一至三年，运行周期则可达五至十年，在这么长的时间内，除了要改正软件中残留的错误外，还可能多次更新软件的版本，以适应改善运行环境和加强产品性能等需要，这些活动也属于维护工作的范畴。能不能做好这些工作，将直接影响软件的使用寿命。

维护是管理信息系统生命周期中花钱最多、延续时间最长的活动。有人把维护比成“墙”或“冰山”，以形容它给软件生产所造成的障碍。不少单位为了维护已有的软件，竟没有余力顾及新软件的开发。近年来，从软件的维护费用来看，已经远远超过了系统的软件开发费用，占系统硬、软件总投资的60%以上。典型的情况是，软件维护费用与开发费用的比例为2：1，一些大型软件的维护费用甚至达到了开发费用的40至50倍。

2. 维护工作中常见的问题

一个系统的质量高低和系统的分析、设计有很大关系，也和系统的维护有很大关系。在维护工作中常见的绝大多数问题，都可归因于软件开发的方法有缺点。在软件生存周期的头两个时期没有严格而又科学的管理和规划，必然会导致在最后阶段出现问题。下面列出维护工作中常见的问题：

(1) 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码而没有说明文档，则会出现严重的问题。

(2) 需要维护的软件往往没有合适的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。

(3) 当要求对软件进行维护时，不能指望由开发人员来仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已不在附近了。

(4) 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法论，否则修改软件既困难又容易发生差错。

上述种种问题在现有的没采用结构化思想开发出来的软件中，都或多或少的存在着。使用结构化分析和设计的方法进行开发工作可以从根本上提高软件的可维护性。

三、系统的可维护性

为了使系统易于维护，下面对系统的可维护性进行讨论。

软件可维护性可以定性的定义为：维护人员理解、改正、改动和改进这个软件的难易程度。提高可维护性是开发管理信息系统所有步骤的关键目标，系统是否能被很好的维护，可用系统的可维护性这一指标来衡量。

系统的可维护性可通过以下方面来衡量。

1．可理解性

指别人能理解系统的结构、界面功能和内部过程的难易程度。模快化、详细设计文档、结构化设计和良好的高级程序设计语言等，都有助于提高系统的可理解性。

2．可测试性

诊断和测试的容易程度取决于易理解的程度。好的文档资料有利于诊断和测试，同时，程序的结构、高性能的调试工具以及周密计划的测试工序也是至关重要。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在系统维护时，应该充分利用在系统调试阶段保存下来的调试用例。

3．可修改性

诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模快的藕合、内聚、作用范围与控制范围的关系等，都对可修改性有影响。

4．软件文档

文档是软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。

软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计，实现和测试等各方面的内容。

总的说来，软件文档应该满足下述要求：

（1）必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用；

（2）必须描述怎样安装和管理这个系统；

（3）必须描述系统需求和设计；

（4）必须描述系统的实现和测试，以便使系统成为可维护的。

5． 可维护性复审资料

可维护性是所有软件都应具备的基本特点，必须在开发阶段保证软件具有可维护的特点。在软件工程的每一个阶段都应考虑并提高软件的可维护性，在每个阶段结束前的技术审查和管理复查中，应该着重对可维护性进行复审。

在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。

在正式的和非正式的设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分作准备。

代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。

每个测试步骤都可以提示在软件正式交付使用前，程序中可能需要做预防性维护的部分。在测试结束时进行最正式的可维护性复审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的，而且为了便于修改和管理已经编目归档了。

在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。

维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果。

每当对数据、软件结构、模块过程或任何其它有关的软件特点做了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。在以后的维护工作中很可能因文档不完全符合实际而不能正确理解软件，从而在维护中引入过多的错误。

用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。

如果在软件再次交付使用之前，对软件配置进行了严格的复审，可大大减少文档的问题。事实上，某些维护要求可能并不需要修改软件设计或源程序代码，只是表明用户文档不清楚或不准确，因此只需要对文档作必要的维护。

上述可维护性诸因素之间是有密切联系的。事实上，维护人员不可能修改一个他还不理解的程序，同样，如果不进行完善的诊断和测试，一个看来是正确的修改有可能导致其它错误的产生。

在实际应用中，也可通过某些其它指标来间接地对系统的可维护性进行定量描述，例如：识别问题的时间；管理上的延迟时间；维护工具的收集时间；分析和诊断问题的时间；修改的时间；调试时间；复查时间；恢复时间。

为了从根本上提高软件的可维护性，人们试图通过直接维护软件规格说明来维护软件，使用结构化分析和设计的开发方法就是提高系统可维护性的根本方法之一。

四、系统维护的内容和类型

根据维护活动的目的不同，可把维护分成改正性维护、适应性维护、完善性维护和安全性维护四大类。另一方面，根据维护活动的具体内容不同，可将维护分成程序维护、数据维护、代码维护和设备维护这四类，下面分别对维护的内容和类型作简要说明。

1．按维护活动的目的分类有：

（1） 改正性维护

在上一章中曾经说过，系统测试不可能发现一个大型系统中所有潜藏的错误，所以，在大型软件系统运行期间，用户难免会发现程序中的错误，这就需要对错误进行诊断和改正。

（2） 适应性维护

由于计算机科学技术的迅速发展，新的硬、软件不断推出，使系统的外部环境发生变化。这里的外部环节不仅包括计算机硬件软件的配置，而且包括数据库、数据存贮方式在内的“数据环境”。为了适应变化了的系统外部环境，就需要对系统进行相应的修改。

（3） 完善性维护

在系统的使用过程中，由于业务处理方式和人们对管理信息系统功能需求的提高，用户往往会提出增加新功能或者修改已有功能的要求，例如修改输入格式，调整数据结构使操作更简单、界面更漂亮等等。为了满足这类要求就需要进行完善性维护。

（4）安全性维护

管理信息系统要收集、保存、加工和利用全局的或局部的社会经济信息，涉及到企业、地区、部门乃至全国的财政、金融、市场、生产、技术等方面的数据、图表和资料。随着病毒和计算机罪犯的出现，管理信息系统对安全性和保密提出了更为严格和复杂的要求。除了建立严格的防病毒和保密制度外，用户往往会提出增加防病毒的功能和保密的新措施，而且随着更多的病毒出现，有必要定期进行防病毒功能的维护和保密措施的维护。

2．按维护活动的内容分类有

（1）程序的维护

程序的维护指改写一部分或全部程序，程序维护通常都充分利用原程序。修改后的原程序，必须在程序首部的序言性注释语句中进行说明，指出修改的日期、人员。同时，必须填写程序修改登记表，填写内容包括：所修改程序的所属子系统名、程序名、修改理由、修改内容、修改人、批准人和修改日期等。

程序维护不一定在发现错误或条件发生改变时才进行，效率不高的程序和规模太大的程序也应不断地设法予以改进。一般说来，管理信息系统的主要维护工作量是对程序的维护。

(2)数据的维护

数据维护指的是不定期的对数据文件或数据库进行修改，这里不包括主文件或主数据库的定期更新。数据维护的内容主要是对文件或数据中的记录进行增加、修改和删除等操作，通常采用专用的程序模块。

(3)代码的维护

随着用户环境的变化，原由的代码已经不能继续适应新的要求，这时就必须对代码进行变更。代码的变更（即维护）包括订正、新设计、添加和删除等内容。当有必要变更代码时，应有现场业务经办人和计算机有关人员组成专门的小组进行讨论决定，用书面格式写清并事先组织有关使用者学习，然后输入计算机并开始实施性的代码体系。代码维护过程中的关键是如何使新的代码得到贯彻。

(4)设备的维护

管理信息系统正常运行的基本条件之一就是保持计算机及外部设备的良好运行状态。因此，计算机室建立相应的规章制度，有关人员要定期的对设备进行检查、保养和杀病毒工作，应设立专门设备故障登记表和检修登记表，以便设备维护工作的进行。

综上所述，系统维护应包括对系统的改正、改变和改进这三个方面，而不仅仅局限于改正错误。

五、系统维护的步骤、组织和管理

1．系统维护的步骤

不少人往往认为系统的维护要比系统开发容易得多，因此，维护工作不需要预先拟定方案或加以认真准备。实际情况并不是这样，许多情况下，维护比开发更困难，需要更多的创造性工作。因此，首先维护人员必须用较多的时间理解别人编写的程序和文档，且对系统的修改不能影响该程序的正确性和完整性。其次，整个维护的工作又必须在所规定的很短时间内完成。

图7-4-1简要说明了维护工作的全过程的步骤，从图7-4-1中可以看出，在某个维护目标确定以后维护人员必须先理解要维护的系统；然后建立一个维护方案；由于程序的修改涉及面较广，某处修改很可能会影响其它模块的程序，所以建立维护方案后要加以考虑的重要问题是修改的影响范围和波及面的大小；然后按预定维护方案修改程序；还要对程序和系统的有关部分进行重新测试，若测试发现较大问题，则要重复上述步骤。若通过，则可修改相应文档并交付使用结束本次维护工作。

必须强调的是，维护是对整个系统而言的。因此，除了修改程序、数据、代码等部分以外，必须同时修改涉及的所有文档。

从图7-4-1还可以看出，系统维护和系统开发有许多共同之处，所以前几章介绍的开发技术和工具在这里都可以使用。

图7-4-1 维护活动的步骤

2．维护的组织和管理

从本质上讲，维护工作可以看成开发工作的一个缩影。而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。为了有效的进行维护工作，首先必须建立一个维护组织，由这个维护组织确定维护报告、进行维护工作的评价，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。

（1） 维护组织

虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式的委托责任也是绝对必要的。维护是软件开发单位的责任。维护组织可由软件开发单位根据本身规模的大小，指定一名高级管理人员担任，或者由高级管理人员和专业人员组成维护领导小组。管理的内容，应包括对申请的审查与批准、维护活动的计划与安排、人力资源的分配、批准并向用户提供维护的结果（例如软件的新版本），以及对维护工作进行评价与分析等。其责任是负责管理本单位开发的软件维护工作。

维护组织应在维护活动开始之前就明确维护责任，这样做可以大大减少维护过程中可能出现的混乱。并根据对维护工作定量度量的结果，做出关于开发技术、语言选择、维护工作量规划、资源分配及其它许多方面的规定，确保维护工作有效的进行。而且可以利用这些数据去分析评价维护工作的质量。

具体的维护工作，可以由原开发小组承担，也可以指定专门的维护小组。每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务作出评价以后，提交给维护授权人决定应该进行的活动。

(2) 维护报告

应用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护申请表---有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境（包括输入数据，全部输出数据，以及其它有关信息）。对于适应性和完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。

维护申请表是一个外部产生的文件，它是计划维护活动的基础。维护组织内部应该制定出一个软件维修报告，它给出下述信息：

<1> 满足维护申请表中提出的要求所需要的工作量；

<2> 维护申请要求的性质；

<3> 这项申请要求的优先次序；

<4> 与修改有关的事后数据。

在拟订进一步的维护计划之前，把维护报告提交给维护授权人审查批准。

(3) 维护的事件流

图7－4－2 维护的事件流

图7－4－2描绘了由一项维护申请而引出的一串事件。首先根据申请要求确定维护的类型。用户常常把一项要求看作是为了改正软件的错误（改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。

从图7－4－2描绘的事件流看到，对一项改正性维护要求的处理，从估量错误的严重程度开始。如果是一个严重的错误（例如，一个关键性的系统不能正常运行），则在系统指导员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护将列入到改正项目表中和其它要求软件开发资源的任务一起统筹安排。

安全性、适应性和完善性维护的申请要求沿着相同的事件流前进。首先确定每个维护申请要求的优先次序，并且安排要求的工作时间，就好象它是另一个开发任务一样（从所有意图和目标来看，它都属于开发工作）。如果一项维护要求的优先次序非常高，可能立即开始维护工作，优先次序低可列入开发项目表。

不管维护类型如何，都需要进行同样的维护过程。维护过程包括修改软件设计，复查，必要的代码修改，单元测试和集成测试（包括使用以前的测试用例），验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。

当然，也有并不完全符合上述事件流的维护要求。当发生恶性的软件问题时，就出现所谓的“救火”维护要求，这种情况需要立即进行维护工作解决问题。如果对一个组织来说，“救火”是常见的过程，那么必须怀疑它的管理能力和技术能力。

在完成软件维护任务之后，进行环境复查常常是有好处的。一般说来，这种复查试图回答下述问题：

<1> 在当前环境下设计、编码、或测试的哪些方面能用不同的方法进行？

<2> 哪些维护资源是应该有而事实上是没有的？

<3> 对于这项维护工作什么是主要的（以及次要的）障碍？

<4> 要求的维护类型中有预防性维护吗？

环境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效的管理软件组织十分重要。

(4) 维护记录

维护记录是维护管理员评价维护工作有效性的主要依据。建立维护记录遇到的第一个问题就是，哪些数据是值得记录的？一般维护记录主要应包括以下三方面的内容：

<1>维护前程序的情况。例如程序的名称，语句或指令条数，所用的语言，安装启用日期以及启用以来运行的次数和其中运行失效的次数等；

<2>维护中对程序修改的情况。例如修改程序的层次和标识，因程序变动而增加和删除的源语句数，修改日期与修改人，以及每一项改动耗费的人─时数；

<3>其它的重要数据，如维护申请单的编号，维护的类型，维护起止日期，耗用的总人－时数，维护完成后产生的净收益等。

维护记录在每次维护完成后填写，它是软件配置的组成部分，也可以存入配置管理数据库，供需要时查询。应该为每项维护工作收集上述数据。

(5)评价维护活动

缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述七个方面度量维护工作：

<1> 每次程序运行平均失效的次数；

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

<3> 平均每个程序、每种语言、每种维护类型所做的程序变动数；

<4> 维护过程中增加或删除一个源语句平均花费的人时数；

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

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