第五节 系统修改工作的组织

信息系统的各项工作都应该有严密的工作规程和工作步骤，我们以系统的修改作为例子，进行比较详细的讨论。

前面已经讲过，由于软件可靠性问题，由于社会环境的不断变化，由于用户需求的不断扩充，系统的修改是不可避免的。但是，对于这种修改，决不能听任自流，否则，系统不但不会扩展功能，日趋完善，而且会使它越改越乱，以至瓦解瘫痪。

例如，操作人员或者使用者发现系统中有一处提示符是两个大于号（＞

＞），他们感到使用不大方便，建议改为一个大于号（＞）。他们找到某一程序员，询问能否进行这样的改动。从程序员的角度来看，这件事情很简单的，只要找出相应的程序块，找到相应的语句，修改一两个字符就行了。然而，当初设计者为什么采用两个大于号，这一点无论是操作人员和使用者， 还是程序员都是不清楚的。很可能一个大于号在系统中还有别的用处，还可能在内部数据的传递和处理中，要用两个大于号和一个大于号进行某种区分。因此，这样的修改可能从局部来看，可以带来某些方便，但是对于全局来说，却可能造成无法预料的后果。如果这样改下去，系统研制时所精心设计的结构就被破坏，系统研制所留下的资料与系统的实际情况就会不相符合，很快就会导致系统的混乱以至无法工作。因此，这种修正方式是不能允许的。

不论是操作人员还是使用者，对系统有任何修改要求时，都必须填写正式的申请修改的表格，向系统的主管人员提出正式的申请。在申请修改的表格中，要明确地指出修改的理由、修改的内容与要求，并有明确的提出时间与申请人。系统主管人员接到这样的申请之后，则应该根据他对系统全局的了解，判断这一修改要求是否可行。有的修改要求从局部看是可行的，从全局来看则是不可行的，在这种情况下，系统的主管人员就应该驳回申请修改的要求，并向申请人说明，为什么不能进行该项修改。如果所提的修改要求是可行的，则需要进一步考虑目前是否迫切需要，一般地说，如果属于改错和适应环境变化，则应该尽快修改，如果是属于扩充功能则需要考虑其紧迫性，作出合理的安排。同时，还要估计修改所需要的工作量和我们现有的人力。根据这些情况，对于所要进行的修改作出安排，确定修改的步骤和时间。

在确定要进行某项修改之后，系统的主管人员应该向程序员正式下达任务。下达任务时，应该把系统中有关模块的全部资料（包括模块设计任务书、源程序、变量说明、调试报告、输出或显示样件）交给程序员，使他确切地掌握原模块的设计思想、实现方法及其他有关情况，同时把修改要求（即申请修改的表格，有可能有所修改）交给程序员，限定一定的工作期限，正式地把修改任务下达给程序员。这里有两点要注意。第一，分工必须明确，系统主管人员负责保证系统结构不被破坏，程序员保证本模块的正确修改。第二，修改期间，原系统仍在运行，因此，往往是把所要修改的模块复制出来， 交给程序员去修改。

程序员完成所要求的修改之后，系统主管人员就可以验收这个新的模块。除了如同系统研制时验收模块那样，详细考察模块的功能之外，还应要求程序员把他所做的修改写成文字材料，说明修改了哪些地方，功能有什么变化，使用方式有什么变化。这些材料和原模块的资料一起收回，妥善保存

起来。这样，系统的档案资料就能和系统的实际情况始终保持一致。

验收之后，系统主管人员就可以选择适当的时机（大家都不用系统的时候），从系统中移出原模块，把新的模块换进去。为了安全起见，不是删除原模块，而是用改名的办法把它保存起来，以防万一。如果新模块出现了什么意想不到的情况，仍可以取出旧模块继续使用。这样的修改对于系统功能和使用方法会带来一些变化，因此，系统的主管人员需要向操作人员及所有使用者发出通报，明确地指出从何时起系统换了新的版本，新的版本在功能和使用方法上与原先的系统的区别，为了便于区分，常常采取把版本编号的办法。为了使版本的更换不要过于频繁，常常是把若干项修改作为一批，同时更换与通报。

这样的工作步骤看起来十分繁琐，然而对于维持系统的正常工作与不断改善，都是非常必要的。这里的关键在于系统的主管人员要负责维护系统的完整性，他需要掌握系统的全局，对系统的修改及发展方向做到心中有数。这一工作是不能由操作员和程序员代替的，因为，他们并不掌握系统的全局。

我们在这里只是作为一个例子详细讨论了系统的修改工作，事实上，数据的录入、例行的操作、临时要求的满足也都应有严密的工作规程和工作步骤。限于篇幅，不再详细说明。