|
|
|
|
|
|
|
|
|
|
|
要强调的是，系统的修改往往会“牵一发而动全身”。程序、文件、代码的局部修改都可能影响系统的其他部分。因此，系统的维护工作应有计划有步骤的统筹安排，按照维护任务的工作范围、严重程度等诸多因素确定优先顺序，制定出合理的维护计划，然后通过一定的批准手续实施对系统的修改和维护。
|
|
|
|
|
|
（1）提出维护或修改要求。操作人员或业务领导用书面形式向系统维护工作的主管人员提出对某项工作的修改要求。这种修改要求一般不能直接向程序员提出。
|
|
|
|
（2）领导审查并做出答复，如同意修改则列入维护计划。系统主管人员进行一定的调查后，根据系统的情况和工组人员的情况，考虑这种修改是否必要、是否可行，做出是否修改、何时修改的答复。如果需要修改，则根据优先程度的不同列入系统维护计划。计划的内容应包括维护工作的范围、所需资源、确认的需求、维护费用、维护进度安排以及验收标准等。
|
|
|
|
（3）领导分配任务，维护人员执行修改。系统主管人员按照计划向有关的维护人员下达任务，说明修改的内容、要求、期限。维护人员在仔细了解原系统的设计和开发思路的情况下对系统进行修改。
|
|
|
|
（4）验收维护成果并登记修改信息。系统主管人员组织技术人员对修改部分进行测试和验收。验收通过后，将修改的部分嵌入系统，取代旧的部分。维护人员登记所做的修改，更新相关的文档，并将新系统作为新的版本通报用户和操作人员，指明新的功能和修改的地方。
|
|
|
|
维护的目的是为了延长系统的寿命并让其创造更多的价值。但每修改一次，潜伏的错误就可能增加一次。这种因修改而造成的错误或其他不希望出现的情况称为维护的副作用。维护的副作用有编码副作用、数据副作用和文档副作用。
|
|
|
|
（1）编码副作用。在使用程序设计语言修改源代码时可能引入错误。例如，删除或修改一个子程序；修改文件的打开或关闭；把设计上的改变翻译成代码上的改变等。为了避免这类错误，要在修改工作完成后进行测试，直至确认和复查无错为止。
|
|
|
|
（2）数据副作用。数据副作用是修改软件信息结构导致的结果。例如，重新定义局部或全局的常量；增加或减少一个数组；重新初始化控制标志或指针等。为了避免这类错误，一是要有严格的数据描述文件，即数据字典系统；二是要严格记录这些修改并进行修改后的测试工作。
|
|
|
|
（3）文档副作用。对数据流、软件结构、模块逻辑或任何其他有关特性进行修改时，必须对相关的技术文档进行相应修改。如果对可执行软件的修改没有反映在文档中，就会产生文档副作用。例如，修改交互输入的顺序或格式没有正确地记入文档中；过时的文档内容、索引和文本可能造成冲突等。为了避免这类错误，要在系统交付之前对整个系统配置进行评审。
|
|
|
|
总之，系统维护工作是信息系统运行阶段的重要工作内容，必须予以充分的重视。维护工作做得越好，信息系统的作用才能够得以充分发挥，信息系统的寿命也就越长。
|
|
|
