首页 百科知识 物流信息管理系统的维护

物流信息管理系统的维护

时间:2022-07-15 百科知识 版权反馈
【摘要】:621 系统维护的目的与任务物流信息系统在完成系统实施并投入正常运行后,就进入了系统运行与维护阶段。系统维护的目的是保证信息系统正常而可靠地运行,并能使系统不断得到改善和提高,以充分发挥作用。信息系统维护是信息系统管理的重要工作内容,其工作量是十分巨大的。系统维护的费用往往占整个系统生命周期总费用的60%以上。如系统的当前情况、维护的对象、维护工作的复杂性与规模。

621 系统维护的目的与任务

物流信息系统在完成系统实施并投入正常运行后,就进入了系统运行与维护阶段。一般信息系统的使用寿命短则4~5年,长则达10年以上。在系统的整个使用寿命中都伴随着系统维护工作的进行。系统维护的目的是保证信息系统正常而可靠地运行,并能使系统不断得到改善和提高,以充分发挥作用。系统维护的任务就是要有计划、有组织地对系统进行必要的改动,以保证系统中的各个要素不管环境如何变化始终是最新的。

信息系统维护是信息系统管理的重要工作内容,其工作量是十分巨大的。随着信息系统应用的深入和使用寿命的延长,系统维护的工作量将越来越大。系统维护的费用往往占整个系统生命周期总费用的60%以上。系统维护工作属于 “继承性”工作,不能只重视开发而轻视维护,只重视短期行为而忽视长远利益。

622 系统维护的对象与类型

1系统维护的对象

系统维护是面向系统中各种构成因素的,按照维护对象的不同,系统维护的内容可分为以下几类。

(1)系统应用程序维护。系统的业务处理过程是通过应用程序的运行而实现的,一旦程序发生问题或业务发生变化,就必然引起程序的修改和调整,因此系统维护的主要活动是对程序进行维护。

(2)数据维护。业务处理对数据的需求是不断发生变化的,除了系统中主体业务数据的定期正常更新外,还有许多数据需要进行不定期的更新,或随环境和业务的变化而调整,以及增加数据内容、调整数据结构等。此外,数据的备份与恢复也是数据维护的工作内容。

(3)代码维护。随着系统应用范围的扩大、应用环境的变化,系统中的各种代码往往需要进行一定程度的增加、修改、删除,或设置新的代码。

(4)硬件设备维护。主要是指对主机及外围设备的日常维护和管理,如机器部件的清洗、润滑,设备故障的检修,损坏部件的更换等。

2系统维护的类型

按照软件维护的不同性质划分为以下四种类型。

(1)纠错性维护。系统测试不可能发现系统存在的所有错误,故而有可能在系统投入运行后,在频繁的实际应用过程中暴露出系统内隐藏的错误。诊断和修正系统中遗留的错误就是纠错性维护。

(2)适应性维护。适应性维护是为了使系统适应环境的变化而进行的维护工作。一方面,硬件的更新周期越来越短,新的操作系统和原来操作系统的新版本不断推出,外围设备和其他系统部件经常有所增加和修改,这就必然要求信息系统能够适应新的软硬件环境,以提高系统的性能和运行效率;另一方面,信息系统的使用寿命在延长,超过了最初开发这个系统时应用环境的寿命,即应用对象也在不断发生变化,机构的调整、管理体制的改变、数据与信息需求的变更等都将导致系统不能适应新的应用环境。如代码改变、数据结构变化、数据格式和输入输出方式变化、数据存储介质变化等,都将直接影响系统的正常工作。因此有必要对系统进行调整,使之适应应用对象的变化,以满足用户的要求。

(3)完善性维护。在系统的使用过程中,用户往往要求扩充原有系统的功能,增加一些软件需求规范书中没有规定的功能与性能特征,以及改进处理效率和编写程序。例如,将几个小程序合并成一个单一的运行良好的程序,从而提高处理效率;增加数据输出的图形方式;增加联机在线帮助功能;调整用户界面等。

(4)预防性维护。系统维护工作不应总是被动地等到用户提出要求后才进行,应进行主动的预防性维护,即选择那些还有较长使用寿命,目前尚能正常运行,但可能将要发生变化或调整的系统进行维护,目的是通过预防性维护为未来的发展与调整奠定更好的基础。根据对各种维护工作分布情况的统计得知,一般纠错性维护占21%,适应性维护占25%,完善性维护达到50%,而预防性维护及其他类型的维护仅占4%。

3信息系统的可维护性

从系统维护的特点可以看到,系统维护工作直接受系统可维护性的影响。可维护性是对系统进行维护的难易程度的衡量。影响系统可维护件的因素主要有以下3个。

(1)可理解性。表现为理解系统的结构、接口、功能和内部过程的难易程度。这种理解包括对功能、性能的分析与理解,对原设计的分析与理解及对源程序的分析与理解。在系统中采用模块化方法,使用详细的设计文档,使源程序内部文档规范与完整,设计结构化和选择较好的高级程序设计语言等,都可以提高系统的可理解性。

(2)可测试性。表现为对系统进行测试和诊断的难易程度。系统具有良好的系统文档、可用的测试工具和调试手段是十分重要的,特别是开发阶段的测试方案尤为重要,是进行回归测试和证明修改正确性的基础。

(3)可修改性。表现为对系统各部分进行修改的难易程度。系统的模块化程度,模块之间的耦合、内聚,控制域与作用域的关系和数据结构的设计等都直接影响系统的可修改性。这些问题在系统分析、设计验收时就应充分重视,否则系统将是很难修改的。

上述3个可维护性因素是密切相关的,只有正确地理解才能进行恰当的修改;只有通过完善的测试才能保证修改的正确,防止引入新的问题。

从上面3个因素可以看出,系统的可维护性是很难量化的,但是可以通过能够量化的维护活动的特征来间接地定量估算系统的可维护性。例如1979年吉布(JGilb)提出把维护过程中各项活动所消耗的时间记录下来,用以间接衡量系统的可维护性,其内容包括:识别问题的时间;管理延迟的时间;维护工具的收集时间;分析、诊断问题的时间;修改设计说明书的时间;修改程序源代码的时间;局部测试的时间;系统测试和回归测试的时间;复查的时间;恢复的时间。显然这些数据是可以衡量的,记录这些数据对于了解系统的可维护性是有益的。当然可维护性的定量分析还有其他方法,如新的学科——软件量度学就是专门研究这方面问题的。

4系统维护的计划与控制

1)系统维护的考虑因素

系统的维护不仅范围广,而且影响因素多。通常,在进行某项维护修改工作之前,要考虑下列三方面的因素。

(1)维护的背景。如系统的当前情况、维护的对象、维护工作的复杂性与规模。

(2)维护工作的影响。如对新系统目标的影响、对当前工作进度的影响、对本系统其他部分的影响、对其他系统的影响。

(3)资源要求。如对维护提出的时间要求、维护所需费用 (与不进行维护所造成的损失相比是否合算)、维护所需的工作人员。

2)系统维护的特点

(1)是否采用系统化开发方法对系统维护工作有极大的影响。如果系统开发采用了结构化方法,则系统交付时有完整的软件配置文档,维护的过程也就比较规范。维护从评价设计文档开始,从文档中确定软件结构、数据结构和系统接口等特点。在考虑修改可能带来影响的情况下,设计修正错误的途径,然后修改设计,在与设计相对应的源程序上进行相应的修改,使用测试说明书中包含的测试方案进行回归测试。可见,经过结构化开发的系统将大大减少维护的工作量,提高质量。

(2)系统维护具有很高的代价。由于系统开发人员和其他开发资源越来越多地被束缚在系统维护工作中,开发的系统越多,维护的负担越重。这将导致完全没有时间和精力从事新系统的开发,从而耽误甚至丧失开发良机。此外,如不能及时满足合理的维护要求,将引起用户的不满。维护过程中引入的错误将使系统可靠性下降等问题会带来很高的维护代价。

(3)系统维护工作对维护人员要求较高。因为系统维护所要解决的问题可能来自系统整个开发周期的各个阶段,因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解,从需求、分析、设计一直到编码、测试等,并且应具有较强的程序调试和排错能力,这些对维护人员的知识结构、素质和专业水平有较高的要求。

(4)系统维护工作的对象是整个系统的配置。由于问题可能来源于系统的各个组成部分,产生于系统开发的各个阶段,因此系统维护工作不仅针对源程序代码,还应包括系统开发过程中的全部开发文档。

3)系统维护的组织与管理

系统维护工作不仅仅是技术性工作,为了保证系统维护工作的质量,还需要做大量的管理工作。系统投入运行后,事实上在一项具体的维护要求提出之前,系统维护工作就已经开始了。要做好系统维护工作,应该注意以下几个方面的问题。

(1)建立相应的组织,确定进行维护工作所应遵循的原则和规范化的过程。此外,还应建立一套适用于具体每个子系统的功能模块;应配备系统管理人员,他们的任务是熟悉并仔细研究所负责系统的功能实现过程,甚至对程序细节都要有清楚的了解,以便完成具体的维护工作。系统变更与维护的要求常常来自于系统的一个局部,这种维护要求对整个系统来说是否合理,应该满足到何种程度,应从全局的角度进行权衡。因此,为了从全局协调和审定维护工作的内容,每个维护要求都必须通过维护控制部门的审查批准,才能实施。这个维护控制部门应该由业务管理部门和系统管理部门共同组成,以便于从业务功能和技术实现两个角度控制维护内容的合理性和可行性。

(2)按照严格的步骤进行系统维护。这是为了防止未经允许擅自修改系统,因为无论是用户直接找程序人员,还是程序人员自行修改程序,都将引起系统混乱,如出现不及时更新文档造成程序与文档不一致、多个人修改的结果不一致、局部修改缺乏全局考虑等情况。当然,维护审批过程的环节过多也可能导致反应速度慢,因此当系统发生恶性或紧急故障时,需立即动用资源解决问题,以保证业务工作连续进行。

(3)为了评价维护的有效性,确定系统的质量,记载系统所经历过的维护内容,应将维护的全部内容以文档的规范化形式记录下来。主要包括维护对象、规模、语言、运行和错误发生的情况,维护所进行的修改情况和维护所付出的代价等,应将这些作为系统开发文档的一部分,形成历史资料,以便日后备查。

(4)应注意系统维护的限度问题。系统维护是在原有系统的基础上进行修改、调整和完善,使系统能够不断适应新环境、新需要。但一个系统终会有生命周期结束的时候,当对系统的修改已不再奏效,或修改的困难很多且工作量很大、花费过大,或改进、完善的内容远远超出原系统的设计要求时,就应提出研制新系统的要求,从而开始一个新的系统生命周期。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈