|
项目管理者联盟 | 中国工程管理网 | 中国研发管理网 | |
会员中心 | |
资料库 | |
论坛 | |
博客 |
 |
|
 |
||||
|
|
||||||||||||||||||||||||||||||||
|
标题：系统维护重要性介绍
楼主
|
|
 zode PMB：1500 省份：浙江省 行业：IT软件 注册：2009/2/18 |
系统维护的目的是要保证信息系统正常而可靠地运行，并能使系统不断得到改善和提高，以充分发挥作用。系统维护的任务就是要有计划、有组织地对系统进行必要的改动，以保证系统中的各个要素随着环境的变化始终处于最新的、正确的工作状态。 现实应用中应用部门往往热衷于系统开发，却忽视了贯穿在整个系统生命周期中的系统维护工作，开发工作完成后，开发队伍解散或撤走，系统开始运行后没有配置适当的系统维护人员，致使系统发生问题或环境发生变化时，应用部门被打了个措手不及，甚至最后被迫放弃历尽千辛万苦所建立的信息系统。 信息系统维护的内容包括系统应用程序维护、数据维护、代码维护、硬件设备维护以及机构和人员的编制。系统维护的重点是系统应用软件的维护工作，按照软件维护的不同性质划分为纠错性维护、适应性维护、完善性维护和预防性维护4 种类型。根据对各种维护工作分布情况的统计结果，一般纠错性维护占21％，适应性维护占25％，完善性维护达到50%，而预防性维护及其他类型的维护仅占4％。可见系统维护工作中，半数以上的工作是完善性维护。 一般来讲，系统维护的费用占整个系统生命周期总费用的60％以上，但是容易遭到忽视；另外，由于系统维护工作是乏味的重复性工作，很多技术人员觉得缺乏挑战和创新，因此更重视开发而轻视维护。由于越来越多地系统维护工作束缚了系统开发人员和其他开发资源，开发的系统越多，维护的负担越重，将导致完全没有时间和精力从事新系统的开发，从而耽误甚至丧失了开发良机。此外，合理的维护要求不能及时满足，将引起用户的不满；维护过程中引入新的错误，使系统可靠性下降等问题将带来很大的维护代价。系统维护是信息系统可靠运行的重要技术保障，必须予以重视，应用部门在信息系统维护方面也应注意系统维护人员的稳定性。 可维护性是对系统进行维护的难易程度的度量，影响系统可维护性主要因素是可理解性、可测试性、可修改性，这3 个可维护性因素是密切相关的，只有正确的理解，才能进行恰当的修改，只有通过完善的测试才能保证修改的正确，防止引入新的问题。虽然通过上面3 个因素对于系统的可维护性很难量化，但是可以通过能够量化的维护活动的特征，来间接地定量估算系统的可维护性。比如国外应用部门一般通过把维护过程中各项活动所消耗的时间记录下来，用以间接衡量系统的可维护性，包括识别问题的时间、管理延迟时间、维护工具的收集时间、诊断问题的时间、修改设计说明书的时间、修改程序源代码的时间、局部测试时间、系统测试和回归测试的时间、复查时间和恢复时间。 提高系统可维护性要从系统分析与设计开始，直至系统实施的系统开发全过程，在系统维护阶段再来评价和注意可维护性为时己晚。应用部门应特别强调提高系统可维护性的工作必须贯穿系统开发过程的始终。系统的维护不仅范围广，而且影响因素多。通常，在进行某项维护修改工作之前，要考虑维护的背景，如系统的当前情况、维护的对象、维护工作的复杂性与规模；要考虑维护工作的影响，如对新系统目标的影响、对当前工作进度的影响、对本系统其他部分的影响、对其他系统的影响；要考虑资源的要求，如对维护提出的时间要求、维护所需费用、维护所需的工作人员。 维护工作可分为非生产性活动和生产性活动两部分，前者主要是理解源程序代码的功能，解释数据结构、接口特点和性能限度等。这部分工作量和费用与系统的复杂程度（非结构化设计和缺少文档都会增加系统的复杂程度）、维护人员的经验水平以及对系统的熟悉程度密切相关；后者主要是分析评价、修改设计和编写程序代码等。其工作量与系统开发的方式、方法、采用的开发环境有直接的关系。因此，如果系统开发途径不好，且原来的开发人员不能参加维护工作，则维护工作量和费用呈指数上升。 由于系统维护所要解决的问题可能来自系统整个开发周期的各个阶段，因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解，从需求、分析、设计一直到编码、测试等，并且应具有较强的程序调试和排错能力，这些对维护人员的知识结构、素质和专业水平有较高的要求。由于问题可能来源于系统的各个组成部分，产生于系统开发的各个阶段，因此系统维护工作并不仅仅是针对源程序代码，而且包括系统开发过程中的全部开发文档。系统维护中的编码本身造成的错误比例并不高，仅占4%左右，而绝大部分问题源于系统分析和设计阶段。通常，理解别人编写的程序很难，且难度随着软件配置文档的减少而增加；绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改，如有些模块不够独立，牵一发而动全身；系统维护工作相对缺乏挑战性，使系统维护人员队伍不稳定。系统维护工作是技术性强的管理工作。系统投入运行后，应用部门必须建立相应的组织，确定进行维护工作所应遵循的原则和规范化的过程，并建立一套适用于具体系统维护过程的文档及管理措施，以及进行复审的标准。 信息系统投入运行后，应用部门应设系统维护管理员，专门负责整个系统维护的管理工作；针对每个子系统或功能模块，应配备系统管理人员，他们的任务是熟悉并仔细研究所负责部分系统的功能实现过程，甚至对程序细节都有清楚的了解，以便于完成具体维护工作。系统变更与维护的要求常常来自于系统的一个局部，而这种维护要求对整个系统来说是否合理，应该满足到何种程度，还应从全局的观点进行权衡。因此，为了从全局上协调和审定维护工作的内容，每个维护要求都必须通过一个维护控制部门的审查批准后，才能予以实施，这个维护控制部门，应该由业务管理部门和系统管理部门共同组成，以便于从业务功能和技术实现两个角度控制维护内容的合理性和可行性。 用户的维护申请都以书面形式的维护申请报告向维护管理员提出。对于纠错性维护，报告中必须完整描述出现错误的环境，包括输入/输出数据以及其他系统状态信息；对于适应性和完善性维护，应在报告中提出简要的需求规格说明书。维护管理员根据用户提交的申请，召集相关的系统管理员对维护申请报告的内容进行核评。情况属实，则依维护性质、内容、预计工作量、缓急程度或优先级以及修改所产生的变化结果等，编制维护报告，提交维护管理部门审批。 维护管理部门从整个系统出发，从合理性和技术可行性两个方面对维护要求进行分析和审查，并对修改所产生的影响做充分的估计。对于不妥的维护要求要在与用户协商的条件下予以修改或撤消。通过审批的维护报告，由维护管理员根据具体情况制定维护计划。对于纠错性维护，估计其缓急程度，如果维护要求十分紧急，严重影响系统的运行，则应安排立即开始修改工作；如果问题不是很严重，可与其他维护项目结合起来从维护开发资源上统筹安排；对于适应性或完善性维护要求，高优先级的安排在维护计划中，优先级不高的可视为一个新的开发项目组织开发。维护计划的内容应包括：工作的范围，所需资源，确认的需求，维护费用，维修进度安排以及验收标准等。维护管理员将维护计划下达给系统管理员，由系统管理员按计划进行具体的修改工作。修改后应经过严格的测试，以验证维护工作的质量。 测试通过后，再由用户和管理部门对其进行审核确认，不能完全满足要求的应返工修改。只有经确认的维护成果才能对系统的相应文档进行更新，最后交付用户使用。为了评价维护的有效性，确定系统的质量，记载系统所经历过的维护内容，应将维护工作的全部内容(如维护对象、规模、语言，运行和错误发生的情况，维护所进行的修改情况，以及维护所付出的代价等)，以规范化文档的形式记录下来，形成历史资料备查。 维护产生的修改对于系统也存在一些副作用：对源代码的修改可能会引入新的错误；对数据结构进行修改，可能会带来数据的不匹配等错误，在修改时必须参照系统文件中关于数据结构的详细描述和模块间的数据交叉引用表，以防局部的修改影响全局的整体作用；任何对源程序的修改，如不能对相应的文档进行更新，造成源程序与文档的不一致，必将给今后的应用和维护工作造成混乱。 系统维护人员应职责明确，保持人员的稳定性，对每个子系统或模块至少应安排两个人共同维护，避免对个人的过分依赖。在系统未暴露出问题时，就应着重于熟悉掌握系统的有关文档，了解功能的程序实现过程，一旦提出维护要求，立即高效优质地实施维护。最后，应注意系统维护的限度问题。即当系统生命周期结束的时，应及时采用新系统。
|
| 回复 | 引用 发表时间：2009/2/18 14:22:11 | |
| ！ 您尚未登录，不能回复主题。 现在 登录 注册 |
|
