GB T 14079-1993 软件维护指南.pdf

1、中华人民共和国国家标准软件维护指南发布实施国家技术监督局发布中华人民共和国国家标准软件维护指南国家技术监督局批准实施主题内容与适用范围本标准描述软件维护的内容和类型维护过程及维护的控制和改进本标准适用于软件生存周期的运行和维护阶段主要供软件管理人员和维护人员使用引用标准计算机软件产品开发文件编制指南软件工程术语术语本标准使用中的术语及下列术语自底向上法在层次结构的软件中一种从最低层成份开始逐级向上扩展直到最高层成份的开发方法自顶向下法在层次结构的软件中一种从最高层成份开始逐级向下扩展直到最低层成份的开发方法编译扩展一种程序设计语言的特征这种特征超越了该语言的标准特征但仍可以为一专门的编译程序所

2、接受并加以编译同级评审一种质量保证方法由两个或多个同级程序员互相检查评估以确保被检查内容正确且与软件的其他部分相一致软件维护管理机构为评审修改带来的影响制订维护计划复查修改结果管理维护工作等而设立的机构软件维护主管组织管理和协调维护工作的负责人维护管理人员管理一个或几个软件的维护工作的技术人员软件维护人员具体完成软件维护的工作人员软件维护的内容与类型软件维护是在软件产品交付使用之后为纠正故障改善性能和其他属性或使产品适应改变了的环境所进行的修改活动软件维护一般分为完善性维护适应性维护和改正性维护三种类型完善性维护完善性维护是为扩充功能和改善性能而进行修改和扩充以满足用户变化了的需求主要内容包括

3、为扩充或增强功能而作的修改如扩充解题范围和算法优化为提高性能而作的修改如提高精度节省存储空间等为便于维护而作的修改如增加注释改进易读性适应性维护适应性维护是为适应软件运行环境的变化而作的修改变化的主要内容包括影响系统的规定法律和规则的变化硬件配置的变化如机型终端打印机等的变化数据格式或文卷结构的变化系统软件的变化如操作系统编译系统或实用程序的变化改正性维护改正性维护是为维持系统操作运行对在开发过程产生而在测试和验收时没有发现的错误而进行的改正所必需改正的错误包括设计错误逻辑错误编码错误文档错误数据错误软件维护过程软件生存周期中的维护阶段通常起始于软件产品交付给用户用户验收之时软件维护活动通常可

4、定义成软件生存周期中前几个阶段的重复软件维护与软件开发有许多相同的活动但也有其独特之处维护活动限定在已有系统的框架之内完成维护人员必须在已有的设计和编码结构的约束下作出修改一般系统越旧软件维护越困难和越费时通常软件维护阶段的时间比软件开发的时间长得多但一项具体的软件维护一般比该软件的开发时间短得多软件开发必须从无到有产生所有测试数据而软件维护通常可以使用现有的测试数据进行回归测试有时还要产生新的数据对软件修改及修改后的影响进行必要的测试完成一项软件维护的过程是复杂的下面按顺序列出完成一项软件维护过程的步骤确定修改类型确定修改的需要提出修改请求需求分析认可或否决修改请求安排任务进度设计设计评审编

5、码修改和排错评审编码修改测试更新文档标准审计用户验收安装后评审修改及其对系统的影响其中有几个步骤会经常发生循环但并不是每次修改都要执行所有的步骤软件维护的控制和改进软件维护必须有控制地进行使整个过程中都处于适当的管理和控制之下除了控制预算进度和人员关键在于要由软件维护主管来负责控制和修改系统大量的编码在开发过程中并非都考虑到了维护即使原来是良好设计及良好实现的编码和逻辑也会因无休止的快速排错和修补工作受到破坏所以一个系统不仅在开发时要考虑到维护还要在维护时考虑到将来的维护软件维护的控制软件系统的可维护性常常随着时间的推移而降低这是许多因素综合的结果如果没有为软件维护管理制定严格的条例或条例贯彻

6、不力许多系统都将蜕变到无法继续维护的地步软件维护的目标是保持系统功能和及时满意地响应用户的请求软件维护的控制是保持一个有秩序的维护过程在这个过程中所有的维护请求要正式提出评审给予一个优先级并安排进度确立软件维护的策略软件维护策略的确定是软件维护控制的一个关键步骤软件维护策略应充分地描述软件维护组织的责任权利职能及操作它应全面地考虑到软件系统和它的环境的任何类型变化该策略应由软件维护管理机构制定和支持软件维护策略必须具体地阐述修改的需要和理由修改的责任和步骤规定控制修改软件的过程和步骤使请求的修改从提议到完成有控制地进行为保证维护策略的贯彻执行需进行评审和审计评审和评价所有修改请求所有的修改要求

7、应先提出正规的书面请求评审所有修改请求分析和评价修改请求的类型和频度考虑对修改的需要程度和它可预见的使用所有修改都需有充足的理由评价修改以确保与原来的系统设计和用意不冲突对每个修改都应该仔细考虑其影响应特别强调确定所建议的修改是增强还是降低系统的性能仅当修改的效益超过其成本时方可修改为维护安排进度给每个修改请求分配一个优先级为每个认可的修改请求安排进度遵守安排的进度将代码修改限制于批准的工作范围内软件维护主管必须监督维护人员的工作确保只在授权的工作范围内作修改为有效实行监督必须将所有的维护活动记入文档包括修改请求报告和完成修改后的源程序清单并为系统复原做好安排强制实施文档标准和编码约定必须贯彻

8、编码约定和文档标准以对软件维护人员的所有工作进行经常不断的强制性评审和检查在开始一项新的维护工作之前应当为更新文档分配足够的时间软件维护的改进可维护性是对软件进行修改的难易程度一个系统的可维护性必须放在系统的整个生存周期中加以考虑在系统最初的设计和开发阶段就应考虑到可维护性由于维护阶段的处理过程同开发阶段相似因此许多技术和开发工具也可用在维护阶段为提高软件可维护性应在系统的整个生存周期中综合地使用下列技术和原理编码指南编码指南和标准提供了一种提高系统可维护性的结构和框架它使得系统以一种共同的更易理解的方式进行开发和维护编码应遵循下列基本原则单一高级语言尽可能只用一种符合标准的高级语言编码约定维

9、护人员首先必须克服的困难是编码本身开发人员和维护人员编写大量源码时很少考虑到以后的维护人员结果使得源码的可读性很差源码一定要加注解并用结构化格式编写下列技术可提高程序的可读性尽量采用较简单的方法代码的每节开始行使用行首空格把一系列代码分成段行首空格和字间的间隔是显示从属关系的两种方法用有意义的注释来适当地为代码加说明使用有意义的变量名以表达此数据项是什么以及为何要使用它避免使用相似的变量名在程序的过程函数之间用参数来传递数据在变量名中使用数字时应放在末端用作程序序标签或标号的数字应按顺序给出逻辑上相关的功能应集中安排在同一模块或模块集尽可能使逻辑流向自顶向下避免使用程序语言版本的非标准特征结构

10、化和模块化应采用自顶向下的程序设计方法使程序的静态结构与执行时的动态结构相一致模块化是指用一组小的层次结构的单元或例行程序构成程序其中每个单元或例行程序集完成特定的单一功能模块性不是仅仅将程序分段模块的结构必须遵循下列设计原则一个模块应只完成一个主要功能模块间的相互作用应最少一个模块应只有一个入口和一个出口标准数据定义一定要为系统制定一组数据定义的标准这些数据定义可汇集于数据字典字典项定义了系统中使用的每个数据元素名字属性用途和内容这些名字要尽可能具有描述性和意义正确一致地定义数据标准就会大大简化阅读和理解各模块并确保各模块间的正确通信良好注释的代码好的注释可增强源码的可理解性除了提高程序可读

11、性注释还有两个重要用途即提供程序的用途和历史信息它的起源作者生成和修改日期子程序名和个数以及输入输出需求和格式其次也提供操作控制信息指示和建议来帮助维护人员理解代码中不清楚的部分编译程序扩展使用编译程序的非标准特征会严重影响系统的可维护性如果编译程序更改了或如果系统必须移至新机器则以前的编译程序扩展很可能与新的编译程序相冲突因此最好限制语言的扩展和保留语言基本特征的一致如果需要使用编译程序扩展应编制良好文档加以说明文档编写指南一个系统的文档是良好维护的基础文档编写工作应贯穿系统的整个生存周期应有计划地建立和及时地更新文档使维护人员能很快地找到所需的信息应参照编制文档文档合格的关键不仅是将必需的

12、信息记录下来以保持文档的及时更新和一致而且必须使维护人员能迅速地获得它对于维护人员来说具有受控的存取和修改能力的联机文档是文档的最佳形式如果不能提供联机文档应保证有一机制使维护人员在任何时候能取用硬拷贝的文档编码和评审技术本条列出有助于提高软件可维护性的设计和评审技术自顶向下自底向上法应将自顶向下与自底向上的方法组合起来使用同级评审同级评审是一种质量保证方法参加评审人员务必明白他们不是要评价其他程序员的能力或表现而是分析和评价编码评审内容应包括可维护性审查审查是一种质量评估技术在软件生存周期中检查各阶段工作然后产生一个报告指出发现的错误和提出错误改正要求走查简单的走查方式是让两个维护人员一起讨

13、论正在进行的工作复杂的走查方式可以有一份日程表报告书和一位记录秘书不论何种方式目标是通过公开直接的交流提炼好的主意修改原来的方案测试标准和过程测试是软件维护的关键部分因此测试过程必须强调一致性并以合理的原则为基础测试计划要定义预期的输入测试有效的无效的预期的和出乎意料的情况测试要检查程序是否执行预期任务测试的目的是发现错误而不是证明错误不存在只要有可能测试过程和测试数据均需由其他人完成而不是由做系统实际维护的人来完成软件维护人员的管理管理是改进软件维护过程的主要因素之一管理必须指导怎样维护软件行使对整个过程的控制并保证使用高效的软件维护技术和工具为确保实现成功的维护在维护过程中要有效使用良好的

14、管理技术和方法必须建立软件维护组织机构软件维护机构由维护主管维护管理机构维护管理员和维护人员组成软件维护机构的主要任务是审批维护请求制订并实施维护策略控制和管理维护过程负责软件维护的审查组织评审和验收确保软件维护任务的完成软件维护人员的素质对于有效地进行维护是十分重要的因此应为维护项目选择合格的各级人员下面列出挑选软件维护人员和进行维护管理的要点维护与开发同等重要同样具有难度维护人员应是合格的有责任心的人维护不能当作初级人员放任自流式的培训全体人员应轮流分配去做维护和开发工作出色的维护工作应同出色的开发工作一样受到奖励必须强调对维护人员进行良好的培训轮换分配不应让一个系统或一个系统的主要部分成

15、为某个人的专有领地软件维护与软件重新设计维护是一种不断进行的过程但有时也应考虑是否要重新设计一个软件系统当一个软件已变得易出差错效率降低和耗费增大再对其继续维护的成本效益比可能会超出重新设计一个系统时应考虑是否要重新设计一个软件系统下列特征可帮助管理人员决定是否应重建软件软件经常出错与性能恶化代码越久则经常的更新新的需求和功能增强就越会引起系统的故障和性能恶化程序结构和逻辑流过分复杂具有部分或全部下列属性的软件通常很难维护需重新设计过多使用循环过多使用语句使用不必要的语句过多使用嵌入的常数和文字使用不必要的全程变量使用自我修改的代码使用多入口或多出口的模块使用相互作用过多的模块使用执行同样或相

16、似功能的模块过时的代码过时的代码严重影响新系统的性能发挥在仿真方式下运行采用仿真方法常阻止系统发挥全部能力和所有功能仿真系统往往介于功能上尚可实用但效率较低这二者之间模块或单个子程序非常大此时大模块结构应重新构造分成较小的功能上相关的部分这可增强系统的可维护性过多的资源需求需要过多资源的系统会成为用户的沉重负担因此需考虑是增加更多的计算机设备还是重新设计和实现该系统将易变的参数编在代码中尽可能对程序进行更新以使它们能从输入模块或一个数据表中读入参数难于拥有维护人员用低级语言编写的程序尤其是汇编需大量的时间和人力去维护一般这类语言不为人们广泛了解因此要寻找了解这类语言的维护人员日益困难文档严重不全或失真文档不全过时或失真将造成维护工作极其困难附加说明本标准由中华人民共和国机械电子工业部提出本标准由上海计算机软件技术开发中心负责起草本标准主要起草人朱三元刘光龙王景寅周庆隆