|
|
知识路径： > 信息系统开发和运行管理知识 > 系统维护知识 >
|
被考次数：4次
被考频率：中频率
总体答错率：38%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：10个
|
|
|
|
|
在进行具体的系统维护之前，要首先制定好详细的系统维护计划，将维护工作的各个方面都考虑清楚。
|
|
|
|
|
|
|
|
系统的可维护性是对系统进行维护的难易程度的度量，影响系统可维护性主要有三个方面。
|
|
|
|
（1）可理解性。外来人员理解系统的结构、接口、功能和内部过程的难易程度。
|
|
|
|
|
|
|
|
|
|
系统可维护性的三个方面因素是密切相关的，只有正确地理解，才能进行恰当地修改，只有通过完善的测试才能保证修改的正确，这样才能防止引入新的问题。
|
|
|
|
虽然通过上面三个方面的因素对于系统的可维护性很难量化，但是可以通过能够量化的维护活动的特征，来间接地定量估算系统的可维护性。比如国外企业一般通过把维护过程中各项活动所消耗的时间记录下来，用以间接衡量系统的可维护性，详细内容如下。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
通过对系统可维护性的分析可见，提高系统可维护性应当从系统分析与设计开始，直至系统实施的系统开发全过程，在系统维护阶段再来评价和注意可维护性已为时已晚。企业应特别强调提高系统可维护性的工作必须贯穿系统开发过程的始终。
|
|
|
|
|
|
在制定系统维护计划之前首先要充分了解系统维护的需求，只有这样，才能制定出正确的系统维护计划。系统维护的需求主要源于决策层的需要、管理机制或策略的改变、用户意见及对信息系统的更新换代。而在了解系统维护需求之前，要先确定系统维护项目是什么和该项目相应的维护级别。
|
|
|
|
|
|
|
|
|
|
（2）软件维护：在软件交付使用后，为了改正软件当中存在的缺陷、扩充新的功能、满足新的要求、延长软件寿命而进行的修改工作。
|
|
|
|
（3）设施维护：规范系统监视的流程，IT人员自发地维护系统运行，主动地为其他部门、乃至外界客户服务。
|
|
|
|
其中，系统维护的重点是系统应用软件的维护工作，按照软件维护的不同性质划分为4种类型，即纠错性维护、适应性维护、完善性维护和预防性维护。根据对各种维护工作分布情况的统计结果，一般纠错性维护占21%,适应性维护占25%,完善性维护达到50%,而预防性维护及其他类型的维护仅占4%。可见系统维护工作中，半数以上的工作是完善性维护。
|
|
|
|
|
|
根据系统运行的不同阶段可以实施4种不同级别的维护。
|
|
|
|
（1）一级维护：即最完美的支持，配备足够数量工作人员，他们在接到请求时，提供随时对服务请求进行响应的速度，并针对系统运转的情况提出前瞻性的建议。
|
|
|
|
（2）二级维护：提供快速的响应，工作人员在接到请求时，提供24小时内对请求进行响应的速度。
|
|
|
|
（3）三级维护：提供较快的响应，工作人员在接到请求时，提供72小时内对请求进行响应的速度。
|
|
|
|
（4）四级维护：提供一般性的响应，工作人员在接到请求时，提供10日内对请求进行响应的速度。
|
|
|
|
对于试运行状况或软件大面积推广状态的项目，阶段时间可能存在问题较多且可能严重影响用户日常工作的项目（例如财务软件跨年时期），其维护级别为一级。要求在“维护项目申请单”中明确维护级别，一级维护的联系人必须能够随时被联系。维护级别可以由申请维护部门根据具体情况予以申请调整。根据用户具体的请求，“软件维护工作单”的填写人根据具体情况填写紧急程度一栏时可以参照维护级别。
|
|
|
|
|
|
系统的维护不仅范围广，而且影响因素多。通常，在设计系统维护计划之前，要考虑下列三方面的因素：
|
|
|
|
（1）维护的背景。包括系统的当前情况、维护的对象、维护工作的复杂性与规模。
|
|
|
|
（2）维护工作的影响。包括对新系统目标的影响、对当前工作进度的影响、对本系统其他部分的影响、对其他系统的影响。
|
|
|
|
（3）资源的要求。包括对维护提出的时间要求、维护所需费用（并与不进行维护所造成的损失比是否合算）、维护所需的工作人员。
|
|
|
|
做系统维护的计划要考虑很多个方面，包括维护预算、维护需求、维护系统、维护承诺、维护负责人、维护执行计划、更替等。
|
|
|
|
|
|
系统维护具有很高的代价，一般来讲，系统维护的费用占整个系统生命周期总费用的60%以上。
|
|
|
|
|
|
维护工作可分为非生产性活动和生产性活动两部分，前者主要是理解源程序代码的功能，解释数据结构、接口特点和性能限度等。这部分工作量和费用与系统的复杂程度（非结构化设计和缺少文档都会增加系统的复杂程度）、维护人员的经验水平以及对系统的熟悉程度密切相关；后者主要是分析评价、修改设计和编写程序代码等。其工作量与系统开发的方式、方法、采用的开发环境有直接关系。因此，如果系统开发途径不好，且原来的开发人员不能参加维护工作，则维护工作量和费用将呈指数上升。统计表明，60%～70%的软件费用花在维护方面。
|
|
|
|
（2）许多无形的代价来自维护所产生的效果和影响上。
|
|
|
|
由于越来越多的系统维护工作束缚了系统开发人员和其他开发资源，开发的系统越多，维护的负担越重，将导致完全没有时间和精力从事新系统的开发，从而耽误甚至丧失了开发良机。此外，合理的维护要求不能及时被满足，将引起用户的不满；维护过程中引入新的错误，使系统可靠性下降等问题将带来很高的维护代价。
|
|
|
|
要根据本单位的实际情况进行系统维护预算，包括系统的情况、系统开发人员的能力水平及是否有相关经验、项目维护的级别等。
|
|
|
|
|
|
在制定维护计划前，要先确定详细的维护需求，列出维护需求单。维护需求单中包含的内容有：需求提出部门、需求提出人员姓名、需求提出时间、拟修改子系统名称、拟修改功能名称、具体修改要求、系统负责人签字、功能完成情况记录、功能完成人员姓名、功能完成时间，等等。认真填写该表，充分了解维护需求，以便制定出正确的维护计划。
|
|
|
|
|
|
通过维护实施人员与提出维护要求的人进行具体讨论，可以达成一定的协议与共识，由此制定详细的维护承诺书并签字。维护实施人员要按照维护承诺来完成维护工作，如果维护过程中有任何影响维护承诺实现的问题，并且经多方努力无法解决的，则应该及时与委托方联系。
|
|
|
|
|
|
系统的维护工作一定要慎重，并且对维护人员要求较高。因为系统维护所要解决的问题可能来自系统整个开发周期的各个阶段，因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解，从需求、分析、设计一直到编码、测试等。此外，他们还应具有较强的程序调试和排错能力。这些对维护人员的知识结构、素质和专业水平都有较高的要求。
|
|
|
|
每项维护工作都应由专人负责，并且通过一定的批准手续。维护工作的审批者要对系统非常熟悉，并且能够判断各种维护的必要性、影响范围和产生的后果。当有关人员完成维护修改任务后，由维护小组组织测试并与用户共同验收成果。通过验收后，新的成果可正式投入使用，系统的相应文档应被更新、归档。
|
|
|
|
|
|
根据维护预算、维护需求、维护承诺、维护负责人员情况和现有的设备、技术等各方面条件来制定系统的维护执行计划，这个计划应涉及执行过程中的步骤和细节，应当尽量减少维护期间对系统的正常运行所造成的影响。需要注意的是，采用本地或全局方式把站点资源移至备用站点，就可以完全避免为升级和维护而执行计划内停机。
|
|
|
|
系统中的数据、软件和硬件都有一定的更新、维护和检修的工作规程。这些工作都要有详细的、及时的记载，包括维护工作的内容、情况、时间、执行人员等。这不仅是为了保证系统的安全和正常运行，而且有利于系统的评价及进一步扩充。
|
|
|
|
|
|
系统维护的实施形式有4种，即：每日检查、定期维护、预防性维护、事后维护。
|
|
|
|
根据实际情况决定采用哪种实施方式。对于最重要、最常用并且容易出故障的软件、硬件和设施可以采用每日检查的维护方式；对于运行情况比较稳定的软件、硬件或设施，可以采用定期维护的方式，例如每个月维护一次；预防性维护是对那些还有较长使用寿命，目前正常运行，但可能将要发生变化或调整的系统进行的主动的维护，预防性维护也要定期进行一次；事后维护是在问题已经发生了的情况下，对系统进行维护，这种方式是被动的。某IT出问题了，系统的用户是第一个发现的人，打电话给IT部门，IT部门再去解决问题。不仅工作被动，效率低下，更严重的是造成某些其他后果。应当规范系统监视的流程，IT人员自发地维护系统运行，主动地为其他部门、乃至外界客户服务。将CIO们的角色由急诊大夫晋升为保健医生，也使IT部门由被动转化为主动，成为企业赢利的前沿部门。
|
|
|
