系统维护的工作特点

发布网友 发布时间：2022-04-19 14:42

我来回答

共1个回答

热心网友 时间：2023-08-18 09:34

如果系统开发没有采用结构化分析与设计方法，则相应的维护也只能是非结构化维护。因为这时系统软件配置的惟一成分是程序源代码，一旦有系统维护的需求时，维护工作只能从艰苦的评价程序代码开始。由于没有完整规范的设计开发文档，无程序内部文档，对于软件结构、数据结构、系统接口以及设计中的各种技巧很难弄清，如果编码风格再差一些，则系统维护工作十分艰难，因此，有许多软件人员宁可重新编码，也不愿维护这种系统。另一方面，由于无测试文档，不能进行回归测试，对于维护后的结果难以评价。
相反，如果系统开发采用了结构化方法，则系统交付时有完整的软件配置文档，维护系统接口等特点，在考虑到修改可能带来影响的情况下，设计修正错误的途径。然后修改设计，在与设计相对应的源程序上进行的修改，使用测试说明书中包含的测试方案进行回归测试。可见经过结构化开发的系统，将大大减少维护的工作量，提高软件质量。 首先，有形的代价直接来自维护工作本身，维护工作可分为两部分，一部分为非生产性活动，主要是理解源程序代码的功能，解释数据结构、接口特点和性质限度等。这部分工作量和费用与系统的复杂程度（非结构化设计和缺少文档都会增加系统的复杂程度）、维护人员的经验水平以及对系统的熟悉程度密切相关；另一部分为生产性活动，主要是分析评价、修改设计和编写程序代码等。其工作量与系统开发的方式、方法、采用的开发环境有直接的关系。因此，如果系统开发途径不好，且原来的开发人员不能参加维护工作，则维护工作量和费用呈指数上升。例如，据1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，而维护成本大约是每条指令4000美元。统计表明，60%-70%的软件费用花在维护方面。
另外，许多无形的代价来自维护所产生的效果和影响上。由于开发人员和其他开发资源越来越多地被束缚在系统维护工作中，开发的系统越多，维护的负担越重，这将导致开发人员完全没有时间和潜力和精力从事新系统的开发，从而耽误甚至丧失了开发良机。此外，合理的维护要求不能及时满足，将引起用户的不满；维护过程中引入新的错误，使系统可靠性下降等问题将带来很高的维护代价。 （1）系统的当前情况
（2）维护对象。
（3）维护工作的复杂性与规模。 （1）对新系统目标的影响。
（2）对当前工作进度的影响。
（3）对本系统其它部分的影响。
（4）对其他系统的影响。 （1）对维护提出的时间要求。
（2）维护所需费用（并与不进行维护所造成的损失比是否合算）。
（3）维护所需的工作人员。 系统维护工作并不仅仅是技术性工作，为了保证系统维护工作的质量，需要付出大量的管理工作。系统投入运行后，事实上在一项具体的维护要求提出之前，系统维护工作就已经开始了。系统维护工作，首先必须建立相应的组织，确定进行维护工作所应遵守的原则和规范化的过程，此外还应建立一套适用于具体系统维护过程的文档及管理措施，以及进行复审的标准。信息系统投入运行后，应设系统维护管理员，专门负责整个系统维护的管理工作；针对每个子系统或功能模块，应配备系统管理人员，他们的任务是熟悉并仔细研究所负责部分系统的功能实现过程，甚至对程序细节都有清楚的了解，以便于完成具体维护工作。系统变更与维护的要求常常来自于系统的一个局部，而这种维护要求对整个系统来说是否合理，应该满足到何种程度，还应从全局的观点进行权衡。因此，为了从全局上协调和审定维护工作的内容，每个维护要求都必须通过一个维护控制部门的审查批准后，才能予以实施，是个维护控制部门，应该由业务部门和系统管理部门共同组成，以便从业务功能和技术实现两个角度控制维护内容的合理性和可行性。系统的组织管理如图1：系统维护工作的程序图2：用户的每个维护请求都以书面形式的“维护申请报告”向维护管理员提出，对于纠错性维护，报告中必须完整描述出现错误的环境，包括输入数据、输出数据以及其他系统状态信息；对于适应性和完善性维护，应在报告中提出简要的需求规格说明书。维护管理员根据用户提交的申请，召集相关的系统管理员对维护申请报告的内容进行核实和评价。对于情况属实并合理的维护要求，应根据维护的性质、内容、预计工作量、缓急程序或优先级以及修改所产生的变化结果等，编制维护报告，提交维护控制部门审批。维护控制部门从整个系统出发，从业务功能合理性和技术可行性两个方面对维护要求进行分析和审查，并对修改所产生的影响做充分的估计，对于不妥的维护要求在与用户协商的条件下予以修改或撤销。通过审批的维护报告，有维护管理员根据具体情况制定维护计划。对于纠错性维护，估计其缓急程度，如果维护十分紧急，严重影响系统的运行，则应安排立即开始修改工作；如果维护不是很严重，可与其他维护项目结合起来从维护开发资源上统筹安排；对于适应性或完善性维护要求，高优先级的安排在维护计划中，优先级不高的可视为一个新的开发项目组织开发。维护计划的内容应包括：维护工作的范围、所需资源、确认的需求、维护费用、维修进度安排以及验收标准等。维护管理员将维护计划下达给系统管理员，有系统管理员安计划进行具体的修改工作。修改后应经过严格的测试，以验证维护工作的质量。测试通过后，再由用户和管理部门对其进行审核确认，不能完全满足维护要求的应返工修改。只有经过确认的维护成果才能对系统的相应文档进行更新，最后交付用户使用。
系统维护之所有要按照严格的步骤进行，是为了防止未经允许的擅自修改系统，因为无论是用户直接找程序人还是程序人员自行修改程序，都将引起系统混乱，如出现不及时更新文档造成程序与文档不一致，多个人修改的结果不一致，以及缺乏全局考虑的局部修改等。当然维护审批过程的环节多也可能带来反应速度慢，因此当系统发生恶性或紧急故障时，也即出现所谓“救火”的维护要求是，需立即动用资源解决问题，以保证业务工作的连续进行。
为了评价维护的有效性，确定系统的质量，记载系统所经历过的维护内容，应将维护工作的全部内容以文档的规范化形式记录下来，主要包括维护对象、规模、语言、运行和错误发生的情况，维护所进行的修改情况，以及维护所付出得代价等，作为系统开发文档的一部分，形成历史资料，以便于日后备查。
维护旧意味着对系统进行修改，修改对于系统来讲有一些副作用，即由于修改而出现错误或其他不合要求的行为，这种副作用主要来自3个方面：第一，对源代码的修改可能会引入新的错误，一般可以通过回归测试发现这类副作用；第二，对数据结构进行修改，如局部或全局变量的重新定义，文件格式的修改等，可能会带来数据的不匹配等错误，在修改时必须参照系统文件中关于数据结构的详细描述和模块间的数据交叉引用表，以防局部的修改影响全局的整体作用；第三，任何对源程序的修改，如不能对相应的文档进行更新，造成源程序与文档的不一致，必将给今后的应用和维护工作造成混乱。在系统维护中，应该注意以上3个问题，以避免修改带来的副作用。
另外，在安排系统维护人员工作时应注意，不仅要使每个人员的维护职责明确，而且对每一个子系统或模块至少应安排两个人可以进行维护工作，这样可以避免系统维护工作对某个人的过分依赖，防止由于工作调动等原因，使维护工作受到影响，应尽量保持维护人员队伍的稳定性，在系统运行尚未暴露出问题时，维护人员应着重于熟悉掌握系统的有关文档，了解功能的程序实现过程，一旦维护要求提出后，他们就应快速高质量地完成维护工作。
最后，应注意系统维护的限度问题。系统维护是在原有系统的基础上进行修改，调整和完善。使系统能够不断适应新环境、新需要。但一个系统终会有生命周期结束的时候，当对系统的修改不再奏效，或修改的困难很多且工作量很大、花费过大，以及改进、完善的内容远远超出原系统的设计要求时，就应提出研制新系统的要求，从而开始一个新的系统生命周期。