1、ICS 35.080 L77 道B中华人民共和国国家标准G/T 20157-2006/ISO/IEC 14764: 1999 信息技术软件维护Information technology-Software maintenance (ISO/IEC 14764: 1999 , IDT) 2006-03-14发布中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会2006-07-01实施发布GB/T 20157-2006/ISO/IEC 14764: 1999 目次Tinu-1499UA-AA哇。09，phuni-i句，臼叮，照牛HJVA 的间之。.T J/, RU GU 与巧tAU-9
2、 TH -BH GU 件u录文用项略附用义应事策性引定的意护程料性性和准注维过资tu围合范语标施件护um划范符规术本实软唯言言录考前引12345678附参GB/T 20157-2006/ISO/IEC 14764: 1999 前言本标准等同采用国际标准ISO/IEC14764 :1999(信息技术软件维护)(英文版)。将原文中的本国际标准改为本标准。本标准的附录A是资料性附录。本标准由中华人民共和国信息产业部提出。本标准由信息产业部电子第四研究所归口。本标准由信息产业部电子第四研究所负责起草。本标准主要起草人:罗锋盈、黄家英、王宝艾。I GB/T 20157-2006/ISO/IEC 1476
3、4: 1999 百l本标准阐明了对软件维护过程的要求。如GB/T8566-2001(信息技术软件生存周期过程所述，软件维护是软件产品生存周期中的一个基本过程。维护过程包含维护者的活动和任务。本标准是GB/T 8566系列文件的一部分，并提供了实施指南。本标准详细说明了GB/T8566中的维护过程。本标准只有强制性段落摘自GB/T85660强制性段落包含用应该一词限定的内容，本标准援引的GB/T 8566应该的内容均以方框标明。在许多项目中，特别是在长生存周期项目中，软件维护必然是项目的一个重要注意事项。由于产品成本和时限的约束以及GB/T8566的最佳惯例未得到遵循，交付的软件常常不完善。因而
4、，必需能纠正运行中发现的故障。软件经常需要改进，以满足变更了的用户需求。软件维护可能成为生存周期成本的一个重要部分。本标准面向熟悉软件维护的读者。对不熟悉软件维护的读者，建议在应用本标准之前学习有关知识或经过相应的培训。可以综合运用软件工具、方法和技术进行软件维护。本标准不规定如何执行软件维护过程中的活动和任务，因为这与相互之间的协定和组织结构相关。软件维护需求与执行软件维护时使用的工具是无关的。E GB/T 20157-2006/ISO/IEC 14764: 1999 信息技术软件维护1 范围本标准比较详细地描述GB/T8566所述的维护过程的管理。本标准还定义了各种维护类型，并且提供了在维
5、护过程的策划、执行、控制、评审和评价以及结束等方面的应用指南。本标准的范围涉及到对于具有相同维护资源的多种软件产品的维护。如无另外说明，本标准中的维护指软件维护。本标准给出一种框架;在这个框架中可以根据给定软件产品的范围和规模对各种通用的和专用的软件维护计划加以剪裁，予以执行和评价。本标准提供了框架、准确术语和过程;它们有助于各种技术(工具、技巧和方法)在软件维护中得到一致应用。本标准提供了软件维护的指南。维护过程及其活动均以GB/T8566的定义为基础。本标准规定了软件维护的活动和任务，提出了维护策划要求，但没有讨论软件操作和操作功能，例如，备份、恢复、系统管理，通常这由运行软件的人员执行。
6、本标准在编写上主要针对软件维护人员，附带考虑了负责开发的和质量保证的人员。本标准也可由那些可能为维护计划提供输入的系统(其中包含软件)需方和用户使用。1. 1 目的本标准提供关于管理(或如何执行)维护过程的指南。它指出在采购和运行期间如何运用维护过程。1. 2 应用领域本标准旨在为策划和维护软件产品或软件服务提供指南，与这种维护是在组织内部还是外部执行无关。它不适用于软件运行。本标准旨在针对供、需双方的情况提供指南，双方来自同一个组织时同样适用。对于按照自我赋予任务方式运作的单一方，本标准也适用(GB/T8566)。本标准的意图不是供现货产品的用户使用，除非现货产品被纳入可交付产品(GB/T8
7、566)。例如，在整个组织里维护字处理模板或宏时，这些组织可能要使用本标准。本标准针对的软件产品不是那些一次性使用的或短期解决方案的软件产品。本标准适用于现货产品开发者自我赋予的这些产品的维护任务。它不适用于用户定制的软件产品和作为最终用户应用软件予以维护的产品。维护适用于计算机程序、编码、数据和文档。本标准适用于在软件产品的开发期间创建的各种软件产品，可能包括测试软件、测试数据库、软件测试环境(STE)或软件工程环境(SEE)，等等。本标准适用于所有的维护工作，与生存周期模型(如增量型、瀑布型、演化型)或开发方法(如快速应用、原型、实物模型)无关。1.3 局限本标准描述了软件维护过程的框架，
8、但不规定关于如何执行过程中的活动或任务的细节。本标准第6、7和8章中给出了大量列表，所有这些列表里的内容都不是穷尽的，仅仅是举例。采用本标准的步骤包含在GB/Z18493中。2 符合性依从GB/T8566的要求，即认为符合本标准。G/T 20 157-2006/ISO/IEC 14764: 1999 3 规范性引用文件下列文件中的有关条款通过引用而成为本标准的条款。凡是注日期的引用文件，其随后的所有的修改单(不包括勘误的内容)或修订版本不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/ T 527 1. 2
9、0 信息技术词汇20部分:系统开发CGB/T527 1. 20- 1994 ,eqv ISO/ IEC 2382 20:1990) GB/ T 1526信息处理数据流程图、4 术语和定义GB/ T 8566、G定义适用于本标准4. 1 4.2 4.3 适应性维护在交付后执得注:修改是修正软件产品，以4.4 4.5 4.6 2 维护性计划maintainability pl 一种文档，其中记述了与软件有关的苦注:由开发者准备维护性计划。增强性维护maintenance enhancement 不属于软件纠正的软件变更。注:有两类软件增强:适应性的和完善性的。维护计划maintenance pla
10、n 一种文档，其中记述了与维护某软件产品有关的特定的维护惯例、资源以及活动序列。注:由维护者准备维护计划。产品一旦转入维护阶段，此计划宜立即启动。4. 7 4.8 4.9 GB/T 20 157-2006/ISO/IEC 14764: 1999 维护过程maintenance process 维护过程包含维护者的各种活动和任务。注:当软件产品由于出现问题或需要改进适应性而修改代码和相关文档时，即启动此过程。其目标是修改现行软件产品以保护其完整性，这个过程包括软件产品的迁移和退役。维护大纲maintenance programme 为执行维护计划使用的组织结构、职责、规程、过程及资源。注:可修改
11、请求分为纠正维护予以标识。修改请求也请求分类维护类型4. 10 完善性维护软件产品交付l口注:完善性维护给用4.12 问题报告Problem ReportC 用于标识和描述软件产品中检测4.13 软件工程环境Software Engineering EnvironmentCSEE) 为实施开展软件工程工作所需的一整套自动化工具、固件和硬件。注:自动化工具可以包括(但不限于编译程序、汇编器、链接程序、装载程序、运行系统、调试程序、模拟器、仿真器、测试工具、文挡编制工具及数据库管理系统。4. 14 软件测试环境Software Test EnvironmentCSTE) 对软件进行合格性测试和其他
12、可能测试所需的设施、硬件、软件、固件、规程及文档。注1:这些环境元素可以包括(但不限于)模拟程序、代码分析程序、测试用例生成程序及路径分析程序，还可能包括软件工程环境中所用的元素。MIL-HDBK-34 7J 3 G/T 20 157-2006/ISO/IEC 14764: 1999 4. 15 软件移交software transition 一系列受控和协调的行动，通过这一系列行动，软件开发工作由执行初始软件开发的组织转移到执行软件维护的组织。5 本标准的应用本章阐述维护软件产品所要求的维护过程。5.1 软件维护软件维护是可能在软件生存周期中执行的五个基本生存周期过程之一(GB/T8566)
13、。通过协定或合同，GB/T 8566的获取和供应基本生存周期过程可能启动软件维护基本生存周期过程的过程实施活动。通过提交修改请求或问题报告，GB/T8566的运作基本生存周期过程可能启动软件维护基本生存周期过程。软件维护基本生存周期过程调用开发基本生存周期过程。软件维护生存周期过程使用GB/T8566的文档编制、配置管理、质量保证、验证、确认、联合评审、审核及问题解决等支持类过程。GB/T 8566的组织类生存周期过程包括四个过程。当启动一个维护项目时，维护者将运用GB/T 8566的管理、基础设施及培训11组织类生存周期过程。为实现软件维护过程改进，将援引GB/T 8566的改进过程。本标准
14、的剪裁在GB/T8566中讨论。剪裁适直于非例行事件，如应急维护。5.2 本标准的编排结构后面几章按照适合维护者的处理顺序逐一阐述。第6章是实施注意事项以及当策划维护时应考虑的问题。第7章是综合性策划信息。第8章是维护过程的细节，包含实施维护过程所需的活动和任务。6 实施注意事项6.1 导引软件维护生存周期过程从策划维护工作的过程实施开始，到软件产品退役时结束。它包含由于问题或改进需要而对代码和文档的修改。维护过程的目标是修改现行软件产品，同时保持其完整性。下面给出各个实施注意事项。之所以需要维护过程，是由于软件产品在生存周期里将经历变更。即使软件产品是用计算机辅助软件工程(CASE)工具开发
15、的，仍需要维护。CASE工具有利于维护但没有消除对维护的需求。即使未开发任何应用代码，即，软件产品只包含现货产品，可能仍然需要维护。需方或供方对现货软件产品的维护通常涉及对产品接口(数据的和运行的)的修改。最好对原开发者的隐含的要求和约束加以考虑。情况可能改变，一些原始需求可能不再适用。在GB/T8566的开发、运作及维护过程的执行期间，检测到的所有问题都要记录在案并且按照GB/T8566的问题解决过程实施监控。其间涉及到提交修改请求或问题报告;通常把它们称为变更请求。通过GB/T8566的问题解决过程来分析和解决问题。在这个过程中还应确定所提交的修改请求或问题报告是为了解决问题还是增强能力。
16、GB/T8566的配置管理过程记录并报告修改请求和问题报告的状态。然后，通过配置管理过程的配置控制活动决定是否批准请求。批准的修改请求或问题报告调用维护过程执行。无论采用何种开发生存周期模型(例如，增量型、瀑布型、演化型)或开发方法(例如，快速应用、原型、实物模型)，都可能需要维护。例如，在一边发布新增部件，一边继续开发的情况下，可能要求在安装后予以维护。维护过程可能占用很大一部分生存周期成本。分析所执行维护的类型有助于了解成本。4 GB/T 20 157-2006/ISO/IEC 14764: 1999 6.2 维护类型纠正性维护系指由于软件产品中的实际差错而必需作的更改。软件产品没有满足其
17、需求，就应进行纠正性维护。预防性维护系指由于在软件产品中检测到潜在差错而必需作的更改。预防性维护通常在有安全性要求或涉及到防止寿命减损的软件产品上进行。道应性和完善性更改是对软件产品的增强措施。这些更改不反映在设计规范或发布的软件中。适应性更改是那些为了适应不断变更的环境的需要而作的变更。适应性更改包括为实现新系统接口需求、新系统需求、或新硬件需求而作的变更。完善性更改是为了改进软件产品性能或维护性。为了给用户提供新的功能性改进，或者为创建以前没有的维护文档或改变现行文档而实施逆向工程时，都可能需要完善性更改。软件维护要求变更某个现行的结构或系统，也就是说，一些软件修改将在必须服从设计结构的约
18、束的前提下被引人某现行的体系结构中。因此，采用适应性维护和完善性维护来实现增强往往是昂贵和费时的。增强措施可能消耗很大一部分维护成本。6.3 维护安排需方可与原开发者达成维护协议，或者由独立的第三方作为维护者。维护也可以通过内部双方协议提供。GB/T 8566提供了派生于需方和供方协议的详细任务。不管供方和需方是否属于同一个组织，最好都利用这些详细任务来帮助形成维护协议。具体的维护专题以后讨论。若在交付后或在保修期结束时需方要求由开发者提供软件维护，宜在协议中规定;更新的文档在此协议中规定为可交付产品;并且对所要求的培训作出规定。然后，供方宜准备执行维护任务的规程，使这些规程保持最新状态，并检
19、查维护活动是否符合协议要求和规程。经验表明使用规程有利于提高效率/成本。拟维护的项、维护规程及所需维护时间，应在维护计划中规定。供方(维护者)和需方宜首先达成维护协议，规定所维护的软件产品的修改规程。原开发者和第三方维护者宜采用类似的规程。这些规程应包括:一基本规则z用于确定软件何时能做局部纠正，或何时要求新基线(使用GB/T8566的关于安装和发布的开发过程);一一发布类型描述:取决于发布频度或发布对软件运行的影响(例如，紧急发布，定期发布); 一一方式:向需方通知当前或将来更改的状态时采用的方式;方法t证实更改不会给软件带来其他问题的方法p-一一类别:更改、紧急事件以及与其他待定变更申请的
20、关系的分类。6.4 维护工具控制软件维护成本的潜在方法是使用CASE工具。这些工具辅助软件维护活动。CASE可以看成是一套相互关联的、支持软件开发和维护所有各方面的工具GB/Z18914J。这些相互关联的CASE工具最好以软件工程环境的形式汇集在一起，以支持那些支持软件维护活动的方法、策略、指南及标准。最好也为维护者提供软件测试环境，以便修改后的软件产品能在非运行环境中测试。软件工程环境提供初始开发和修改软件产品的工具。软件测试环境提供测试环境，应用于在非运行环境中测试修改后的软件产品。注明成功运用CASE工具的日期。维护者应仔细策划这些工作GB/Z18914J。6.5 软件测量软件质量是软件
21、产品维护中的重点考虑对象。维护者最好拟订一份软件质量大纲，其中包含GB/T 16260描述的6个软件质量特性。应该对软件维护实施一个过程，用以标识、定义、选择、采用、确认以及改进软件测量的过程。5 GB/T 20 157-2006/ISO/IEC 14764: 1999 作为软件测量的一部分，维护者宜按照资掘消耗量确定纠正性维护、预防性维护、适应性维护和完善性维护的工作量。为了便于维护过程的改进和更确切地掌握维护成本开销情况，要收集、分析和解释有关数据。为了辅助估算生存周期成本，要收集经验度量数据。6.6 过程的文档编制软件的详细维护过程(本标准的第8章)应编制成文档，以便所有的维护人员遵循相
22、同的过程。度量要支持维护过程的改进工作和有关软件过程的改进工作。6. 7 旱期介入开发数据表明，软件维护成本和维护者的软件维护能力在很大程度上受到软件开发过程期间发生或没有发生某些事件的影响。在许多情况下，由于合同或其他原因维护者不能介入。特别是，当维护外包给第三方时，往往没有介入的机会。当主拱酬持他毛主时，维护者即宜介入。维护者的职能宜包括:确保软件产品一一一支持制定软千6. 8. 1 维护性维护性宜在那支持GB/T8566描、宜在软件开发期间维护性需求，定义检查维量需求用于确定维护性的规度量。述南做客规定的定性和定量的软件省维护成本和资源的技术。定百l阶段用于确定数值或指标的各种一旦维护活
23、动开始，这项工作在开弃附珊缤现出来。开发者要实现维护性要求，维护者要监控实现情况。这项工作最好作为软件维护策略的一部分。采用GB/T8566的关键之一是制定软件维护策略(GB/T18493)。因此，要制定维护策略并且策划维护(本标准第7章)。软件维护策略也宜在设计之前制定。维护者早期介入开发有可能节约资金。开发过程中要进行许多活动，包括软件维护的策划。这些活动应反映在软件维护计划(本标准第7.3.2条)中。下列各项影响维护性，宜在选择程序设计语言时加以考虑:一一一语言可移植性;6 -一一语言易读性;一一语言稳定性;一一自带文档;一一对降低程序清晰度的程序设计窍门的容限;一一程序结构化的可能性;
24、一一生产新的发布版本的简易性;一一-数据结构化的可能性;一一编译程序及其他工具的可用性;二一编译程序及其他工具的稳定性;一一辅助生产、调试、配置意度;括这些需求。下一一功能，一一-数据瞄准响维护性的这据流。与其他甜可信的现有程序皂由若干自顶向6.8.2.4 软件编码和测试GB/T 20157-2006/ISO/IEC 14764: 1999 的可用性，以及可靠性和质量需求满的质量特性规范中宜包卡充)，是持续实现维护性库提供详细设计。这项活动产通过GB/T8566描述的这项开发过程活动对软件单元和数据库进行开发、文档编制和测试。软件维护性通过文档质量的升级加以改进。质量文档应提供有助于执行维护过
25、程的信息。利用质量文档改进维护性的建议包括:一一确保易读性;一一避免非结构化代码;一一考虑语言本身的弱点，排除典型的陷阱;一一在详细设计中检测差错;7 GB/T 20157-2006/ISO/IEC 14764: 1999 一一使用有助于差错追踪的技术。6.8.2.5 软件合格性测试这项活动确保每个软件需求的实现都进行符合性测试(GB/T8566)。有关质量的软件需求在这项活动期间测试。保存软件开发期间所用的测试用例，用于修改后的回归测试。另外，为了在开发期间避免重复相同错误，要保留项目的开发历史供维护使用。6.9 软件移交软件移交是-个受控且需协调的活动序列，软件开发由最初开发机构转移到软件
26、维护机构。如果维护职责从一个组织转移到另一个组织，要制定移交计划。此计划涉及:一一硬件、软件、数据及经验由开发者移交给维护者;一一维护者为实现软件维护策略所需要的任务(例如，人员配备、培训、安装、再现维护问题)。6. 10 文档编制维护者往往面临的待维护的软件产品只有很少文档甚至没有文档。如果没有文档，维护者要建立所需文档。文档创建是完善性维护的一部分。这是执行维护功能中的难题。当面临这种形势时，维护者宜进行下列维护准备。a) 了解问题的领域(应用类型)。阅读文档(若可用)，与开发者讨论软件产品(若可用)，并运行软件产品。b) 学习软件产品的结构和组成。清点软件产品，把软件产品置于配置管理下，
27、重建配置管理库中的软件产品，生成调用树，并分析软件产品的结构。c) 确定软件产品做什么。评审规格说明(若可用)，评审整个结构，分析调用树，阅读代码，向其他维护者提供口头说明，并给代码补加注释。d) 定位低优先级的修改请求或问题报告。按上面列出的指南实施时，维护者应编制软件产品文档。必要时，更新或创建文档(如，规格说明、程序员维护手册、用户手册及安装指南)。维护环境中存在各种影响文档的创建和更新的因素，例如:源代码访问、代码分析工具的可用性，运行软件产品以确定性能的能力、以及软件测试环境的可用性。7 软件维护策略7. 1 导引本章讨论软件维护策略的制订。此策略为软件产品维护准备所要求的人力和物力
28、资源。把维护性分析的结果作为维护策划的辅助手段。这种分析宜作为制订维护策略的输入。软件维护策略包括下列各项内容:一一一维护概念;一一维护计划;一一资惊分析。7.2 维护概念8 确定维护概念是制订软件维护策略的第一步。维护概念在首次表述初始软件产品需求时提出。维护概念涉及:一一软件维护范围;一一过程的剪裁;一一指定维护提供者;一一维护成本估算。注:维护概念在维护计划中给出。GB/T 20157-2006/ISO/IEC 14764: 1999 7.2. 1 范围范围与维护者将如何响应有关。要确定维护者的支持程度。预算上的约束往往限定维护的范围。维护范围涉及:一一拟进行的维护的类型;一一拟维护的文
29、档的级别;一一-响应度;一一拟提供的培训级别;交付支持;一一前台支持。7.2.2 过程剪裁维护概念涉及软件交付后的维护任务。不同的机构在维护期间可能执行不同的任务。宜早作尝试以标识这些机构并记入维护概念文档。维护概念也要反映将采用的维护过程。7.2.3 指定维护提供者指定由谁提供维护是一个重要议题，宜早处理并记入维护概念文档。这对内部维护工作同样适用。对外包第三方协议的维护工作，维护概念要注明外包的维护。GB/T8566描述的需方和供方基本过程提供有关获取和供应软件服务的细节。制约维护者指定的基本因素有多种，包括:一一软件产品的寿命;长期成本;一一一启动成本;一一空间的可用性;一-一资格;一一
30、可用性;一一进度安排;一一领域知识。7.2.4 维护成本估算要估算维护成本。成本是维护范围的函数。涉及成本的附加因素是:一一到用户处的差旅费;一一对维护者以及用户的培训费;软件工程环境和软件测试环境的成本和年度维护费;薪水和津贴之类的人员成本。建立维护概念时，要根据有限的可用数据估算成本。随着开发工作的推进，估算要进一步细化。历史度量数据应用作估算维护成本的输入。7.3 维护策划7.3.1 导引维护策划的目的是策划维护活动，并且尽早获取所需的资源，当软件产品移交到维护时立即可供使用。一旦软件维护概念确定，就启动策划，一旦软件进入服务阶段，策划工作将以产生用于指导维护者的维护计划的形式而告结束。
31、7.3.2 维护计划当上述维护概念确定时，要立即开始维护活动和任务的策划。拟订出维护计划后，策划工作也就完成。维护计划在软件开发期间由维护者制订，宜包含用户如何提出更改软件产品的请求。维护计划应包含:一一为何需要维护;9 GB/T 20 157-2006/ISO/IEC 14764: 1999 一一由谁做什么工作;所参与的每个人的角色和职责是什么;一一-工作如何执行;一一可用于维护的资源是什么;一-维护在何处执行;一维护何时开始。7.3.3 维护计划指南10 本条为制订维护计划提供指南，对维护计划中的专题提出建议。根据工作量确定包括哪些专题。a) 导引1) 描述拟支持的系统;2) 3) 4)
32、5) 描述顾客气b) 维护概念1) 2) 3) 4) 剪裁台c) 机构和维2) i ) ii ) iii ) iv) v) 迁移;vi ) 退役;vii ) 问题解决(包括前viii) 培训人员(维护者和周言J, ix) 改进过程。3) 用户角色i ) 验收测试;ii ) 与其他组织的接口。d) 资源1) 人员项目的人员规模。2) 软件确定支持系统(包括系统以及软件工程环境/软件测试环境/工具需求)所需的软件。GB/T 20 157-2006/ISO/IEC 14764: 1999 3) 硬件确定支持系统(包括系统以及软件工程环境/软件测试环境需求)所需的硬件。4) 设施确定设施需求。5) 文
33、档i ) 软件质量计划;ii ) 项目管理计划;iii ) 配置管理计划;iv) 开发文挡;V) 维护手册;vi ) vii ) viii) ix ) 1) 维护2) 经剪f) 培训11确定维护g) 维护记录1) 请求2) 请求、4) 7.4 资源分析制定软件维护策略时和财政资源需求即能确定。和财政资源均宜加以讨论。吗需求是主要的成本因素，同时是使用参数模型和运用经验。模型需要历史上的经验数据。运用经验的最佳途径在于得到经验性的历史数据。建议使用一致同意的标准办法估算维护。单独开展维护人员配备研究，其中涉及确定人力资源的方法和研究结果。7.4.2 环境资源软件开发和维护是专业化活动，需要单独的
34、专用系统。建议软件工程环境和软件测试环境分开。维护者要协助需方策划维护环境。当软件产品的开发和维护的预算已定并且资金到位后，得到早期策划工作中考虑的维护环境就非常关键。7.4.3 财政资源资源的最后一项是财政资源。为了提供有效的维护支持，维护者需要做出预算，其中涉及:11 G/T 20 157-2006/ISO/IEC 14764: 1999 工资;一一培训11(每人每年23周); 一软件许可证的年维护费;-一一差旅费;技术出版物;一一工程和测试环境的硬、软件;工程和测试环境的硬、软件的升级。8 维护过程本章规定软件维护的基本生存周期过程的活动和任务。维护过程包含为修改现行软件产品同时保持其完
35、整性所必需的活动和任务。这些活动和任务是维护者的责任。本标准按步骤描述维护任务，这些步骤是执行维护活动和任务的示例。维护者要确保维护过程在任何软件产品开发之前已经存在并发挥作用。当提出软件产品维护要求时，应启动维护过程。一旦该过程启动，应立即制订维护计划和规程并且分配维护专用资源。软件产品交付后，为响应修改请求或问题报告，维护者应修改代码和相关的文档。软件维护的总目标是修改现行产品同时保护其完整性。这个过程对软件产品的支持从其开始到迁移到新环境、直至退役。软件产品最终退役时本过程即告结束。组成维护过程的活动有:a) 过程实施;b) 问题和修改分析;c) 修改实现;d) 维护评审/验收pe) 迁
36、移;f) 退役。输入由维护活动加以转换或利用以形成输出。各种控制提供指导以确保维护活动产生正确的输出。输出是维护活动产生的数据或对象。对于维护活动所使用的GB/T8566的支持类和组织类生存周期过程给予支持。图2给出维护过程的概貌。过程实施l 图2维护过程12 GB/T 20157-2006/ISO/IEC 14764: 1999 8. 1 过程实施在过程实施期间，维护者建立维护过程期间应执行的计划和规程。维护计划(见本标准第7.3.2条)应与开发计划并行制订。维护者还应建立这项活动期间需要的组织接口。8. 1. 1 输入对过程实施活动的输入包括:一一-旧基线;一一-系统文档;一一修改请求或问
37、题报告。8. 1.2 任务为有效地实施维护过程，维护者应制订维护策略并形成文档。为此，维护者应执行下列任务:一一制订维护计划和规程;一一建立修改请求/问题报告规程;实施配置管理。8. 1.2. 1 维护计划和规程5.5.1.1 维护者应为实施维护过程的活动和任务制订并执行计划和规程，并形成文档。(见GB/T 8566-2001第5.5. 1. 1条)。维护计划应包含所使用的系统维护策略文档，而维护规程应给出更详细的关于如何实际完成维护的方法。为制订有效的维护计划和规程，维护者应执行下列任务:a) 协助需方提出维护概念;b) 协助需方确定维护范围;c) 协助需方分析维护组织的替代方案;d) 确保
38、书面指定软件产品维护者;e) 进行资源分析;f) 估算维护成本;g) 进行系统的维护性评估;h) 确定移交需求;i) 确定移交里程碑;j) 确定应使用的维护过程;k) 以运行规程的形式编制维护过程文挡。8.1.2.2 修改请求/问题报告规程5.5.1.2 维护者应建立接收、记录、追踪问题报告、用户修改请求以及向用户提供反馈的规程。无论何时遇到问题，都应记录并进入问题解决过程(见GB/T8566-2001第6.8条)。维护者应执行下列任务:a) 为修改请求/问题报告制订标识编号方案;b) 为修改请求/问题报告制订分类和排列优先顺序的方案;c) 制订趋势分析规程;d) 确定运行员提交修改请求/问题
39、报告规程;e) 确定如何向用户提供初始反馈;f) 确定如何为用户提供变通办法;g) 确定数据如何录入状态统计数据库;13 G/T 20157-2006/ISO/IEC 14764: 1999 h) 确定向用户提供何种后续反馈。8. 1. 2.3 配置管理维护者应实施(或建立组织接口)配置管理过程(见GB/T8566-2001第6.2条)以管理对现有系统的修改。维护者需要调用GB/T8566中的配置管理过程。8. 1. 3 控制使用联合评审(见GB/T8566中的6.2)来控制过程实施活动的输出。一一问题解决一一用户反馈t移交计划;一一-配置管理t所有的输出均置一一求得批准所选择的修改意见问题和
40、修改分析活动的输入是经过:见8.2.1 输入14 问题和修改分析活动的输入是:一一修改请求/问题报告;一一基线;一一一软件存放库;系统文档。系统文档包括:一一配置状态信息;一一功能需求;百、系统/项目文档以及需求文档。GB/T 20 157-2006/ISO/IEC 14764: 1999 一一接口需求;一一项目策划数据;一一过程实施活动的输出。8.2.2 任务在修改系统前，维护者要分析修改请求/问题报告，以确定其对组织、现行系统和接口系统的影响，应提出可能的解决方案建议并形成文档，并且求得批准实施期望的解决方案。8.2.2.1 修改请求/问题报告分析为确保所要求的修a) 确定维护者b) 确定
41、项目是c) 确定是否d) f) 确定短时g) 确定修改h) 确定对进i) 确定所要求j) 确定实现更改8.2.2.2 验证为确保请求的问题报告有效，a) 制订验证问题的测试策略;、b) 从配置管理中提取受影响的软件c) 安装受影响的版本;d) 运行测试以验证问题，最好用受影响的数据的拷贝ze) 编制测试结果文档。问题报告可能不若由于某些原因，例如数据的机密性，问题不能重现，则应检查其他项，如组织规则、方针和文档。对适应性或完善性维护不要求执行验证任务。8.2.2.3 选项在分析的基础上，维护者应制订实施修改的方案(见GBjT8566-2001中第5.5.2.3条)。维护者应执行下列任务:15
42、GB/T 20157-2006/ISO/IEC 14764: 1999 a) 对修改请求/问题报告赋予优先级别;b) 确定对问题是否有变通办法。如果有，提供给运行者或用户;(这一步骤对适应性或完善性维护不需要)c) 规定修改确认要求;d) 估算修改的规模和范围;e) 提出进行修改的至少三个可供选择的方案;f) 确定这些可选方案对系统硬件的影响;g) 针对每个可选方案进行风险分析。8.2.2.4 文档维护者应将问题/修改请求、分析结果和实施方案形成文档(见GB/T8566-2001中第5.5.2.4条)。执行下列任务za) 验证所有对应的分析和项目文档是否已更新。如果没有文档，则编制文档pb)
43、评审建议的测试策略和进度表的准确性;c) 评审资源估算的准确性;d) 更新状态统计数据库;e) 提出处置建议，指出是否应该批准修改请求/问题报告。8.2.2.5 批准在系统修改前，维护者应按合同规定使选定的修改方案得到批准(见GB/T8566-2001中第5.5.2.5条)。如果不是协议启动的维护，在进行维护时也要得到批准。维护者可以通过执行下列任务得到批准za) 由相应的配置管理组提供针对批准的分析结果;b) 参与有关修改的讨论;。一经批准，立即更新修改请求状态;d) 一经批准，若请求是增强(改进)性的，立即更新需求。8.2.3 控制通过联合评审保持控制(见GB/T8566-2001中第6.
44、6条)。在这项活动的最后应进行风险分析。利用维护过程的问题和修改分析活动的输出，修改先前的资源估算，并且与用户(顾客)一起决定是否推进到修改实施活动。8.2.4 支持问题和修改分析活动使用GB/T8566一2001描述的下列生存周期的支持过程:一一文档编制过程;一一质量保证过程;一一问题解决过程。8.2.5 输出16 这项活动的输出为:一一影响分析;一一推荐的可选方案;一一批准的修改;己更新的文档。GB/T 20157-2006/ISO/IEC 14764: 1999 影响分析包含:一一对问题或新需求的陈述;一一问题或需求评价;-一一所要求的维护类型分类;一一初始优先级别;验证数据(用于纠正性
45、修改); 一一-修改现行系统所要求的初始资源估算。更新的文档包括:测试策略;一一更新的测试文挡，包括测试计划、测试规程和测试报告;一一软件开发文件夹;更新的需求。8.3 修改实施在修改实施活动期间，维护者修改软件产品并测试修改的软件产品。8.3. 1 输入修改实施活动的输入为:一一基线;一一批准的修改请求/问题报告;一一批准的修改文档。基线包括:系统体系结构定义;一一修改请求记录;一一-源代码。批准的修改文档包括:一一影响分析报告;一-问题和修改分析活动的输出。8.3.2 任务维护者执行分析，然后引用GB/T8566描述的开发过程实现修改。8.3.2.1 分析一旦修改请求/问题报告获准，维护者
46、应实施分析并确定需修改的文档、软件单元和版本。这些应形成文档(GB/T8566中第5.5.3.1条)。a) 确定现行系统中拟更改的元素;b) 确定受修改影响的接口元素;c) 确定拟更新的文档;d) 更新软件开发文件夹。17 GB/T 20157一2006/ISO/IEC14764: 1999 8.3.2.2 开发过程维护者应进入开发过程(见GB/T8566-2001第5.3条)以实施修改。开发过程的需求补充如下:a) 应规定测试和评价系统中已修改的与未修改的部分(软件单元、部件和配置项)的准则，并形成文档;b) 应确保新的和已修改的需求完整与正确地实现。同时确保原来的、未修改的需求不受影响。测
47、试结果应形成文档CGB/T8566-2001第5.5.3.2条)。开发过程中的活动宜加以剪裁以满足修改工作的需要。8.3.3 控制修改实施的控制宜包括联合、一一联合评审8.3.5 输出这项活动的息更新一一更新一一修改一一测试一一度量更新的文一一更新一一详细8.4 维护评审和(旦这项活动确保对矶8.4.1 输入维护评审和(或)验收一一修改的软件;一一修改测试结果。8.4.2 任务进行评审确保修改是正确的并且是由于满意完成修改而得到批准的。8.4.2.1 评审维护者应与授权修改的组织一起实施评审以确定已修改的系统的完整性CGB/T8566-2001 第5.5.4.1条)。宜执行下列任务:18 GB
48、/T 20 157-2006/ISO/IEC 14764: 1999 a) 从需求到设计，到编码追踪修改请求/问题报告;b) 验证代码的可测试性;c) 验证编码标准是否得到遵循;d) 验证只对必要的软件部件作了修改;e) 验证新软件部件集成的正确性;f) 检查文档确保其己予更新;g) 执行测试;h) 拟制测试报告。8.4.2.2 批准8.4.3 控制同期过程:二-运行。为了将某个系统迁移到某移所要求的步骤并且形成文档。8.5. 1 输入迁移活动的输入是:旧环境;一一一新环境;一一旧基线;一一一新基线。8.5.2 任务维护者通过以下活动实现迁移:遵循GB/T8566-2001、制订迁移计划、通告
49、此迁移的用户、提供培训、通告完成情况、评估新环境的影响以及归档数据。19 GB/T 20157-2006/ISO/IEC 14764: 1999 8.5.2.1 迁移准备如果一个系统或软件产品(包括数据)从一个老的运行环境迁移到一个新的运行环境，应确保在迁移过程中任何软件或产生修改的数据遵循本标准CGB/T8566-2001第5.5.5.1条)。宜执行下列任务za) 确定附加的或修改的所有软件产品或数据;b) 验证这些任务遵守GB/T8566-2001。8.5.2.2 迁移计划为了恰当控制系统的迁移，、应制订一个迁移计划并实施和形成文档。策划活动应包括用户。计划应包括下列各项:U 需求的分析和迁移的定义;b) 迁移工具的开发;c) 软件产品和数据的变换pd) 迁移的执行;e) 迁移的验证;f) 未来
