|
|
知识路径： > 信息系统运维概述 > 信息系统运维概述 > 信息系统运维的框架 > 信息系统运维的框架 >
|
|
相关知识点：7个
|
|
|
|
|
|
|
（1）是否采用结构化开发方法对系统维护工作有极大影响。如果系统开发没有采用结构化分析与设计方法，则相应进行的维护也只能是非结构化维护。因为这时系统软件配置的唯一成分是程序源代码，一旦有系统维护的需求时，维护工作只能从艰苦的评价程序代码开始。由于没有完整规范的设计开发文档，无程序内部文档，对于软件结构、数据结构、系统接口以及设计中的各种技巧很难弄清，如果编码风格再差一些，则系统维护工作十分艰难，因此，有许多软件人员宁可重新编码，也不愿维护这种系统。另一方面，由于无测试文档，不能进行回归测试，对于维护后的结果难以评价。
|
|
|
|
相反，如果系统开发采用了结构化方法，则系统交付时有完整的软件配置文档，维护的过程也就比较规范。维护从评价设计文档开始，从文档中确定软件结构、数据结构以及系统接口等特点，在考虑到修改可能带来影响的情况下，设计修正错误的途径。然后修改设计，在与设计相对应的源程序上进行相应的修改，使用测试说明书中包含的测试方案进行回归测试。可见经过结构化开发的系统，将大大减少维护的工作量，提高质量。
|
|
|
|
（2）系统维护要付出很高的代价。首先，有形的代价直接来自维护工作本身。维护工作可分为两部分，一部分为非生产性活动，主要是理解源程序代码的功能，解释数据结构、接口特点和性能限度等。这部分工作量和费用与系统的复杂程度（非结构化设计和缺少文档都会增加系统的复杂程度）、维护人员的经验水平以及对系统的熟悉程度密切相关；另一部分为生产性活动，主要是分析评价、修改设计和编写程序代码等。其工作量与系统开发的方式、方法、采用的开发环境有直接的关系。因此，如果系统开发途径不好，且原来的开发人员不能参加维护工作，则维护工作量和费用呈指数上升。例如，据1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，而维护成本大约是每条指令4000美元。统计表明，60%～70%的软件费用花在维护方面。
|
|
|
|
另外，许多无形的代价来自维护所产生的效果和影响上。由于系统开发人员和其他开发资源越来越多地被束缚在系统维护工作中，开发的系统越多，维护的负担越重，这将导致完全没有时间和精力从事新系统的开发，从而耽误甚至丧失了开发良机。此外，合理的维护要求不能及时满足，将引起用户的不满；维护过程中引入新的错误，使系统可靠性下降等问题将带来很高的维护代价。
|
|
|
|
（3）系统维护工作对维护人员要求较高。因为系统维护所要解决的问题可能来自系统整个开发周期的各个阶段，因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解，从需求、分析、设计一直到编码、测试等，并且应具有较强的程序调试和排错能力，这些对维护人员的知识结构、素质和专业水平有较高的要求。
|
|
|
|
（4）系统维护工作的对象是整个系统的配置。由于问题可能来源于系统的各个组成部分，产生于系统开发的各个阶段，因此系统维护工作并不仅仅是针对源程序代码，而且包括系统开发过程中的全部开发文档。
|
|
|
|
（5）系统维护经常遇到的很多问题。系统维护中的绝大部分问题源于系统分析和设计阶段，而编码本身造成的错误比例并不高，仅占4%左右。理解别人编写的程序很难，难度随着软件配置文档的减少而增加。从实际情况来看，绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改，如有些模块不够独立，牵一发而动全身。同时，系统维护工作相对开发工作来讲，不具挑战性，不吸引人，使系统维护人员队伍不稳定。
|
|
|
