软件维护活动
(1) 维护机构
除了较大的软件开发公司外，通常在软件维护工作方面，不保持正式的维护机构。维护往往是在没有计划的情况下进行的。虽然不要求建立一个正式的维护机构，但是在开发部门，确立一个非正式的维护机构则是非常必要的。例如图就是一个维护机构的组织方案。
维护申请提交给一个维护管理员，他把申请交给某个系统监督员去评价。一旦做出评价，由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。
维护管理员、系统监督员、修改负责人等，均代表维护工作的某个职责范围。修改负责人、维护管理员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员在内的小组。系统监督员可以有其他职责，但应具体分管某一个软件包。
在开始维护之前，就把责任明确下来，可以大大减少维护过程中的混乱。
(2) 软件维护工作流程
先确认维护要求。这需要维护人员与用户反复协商，弄清错误概况以及对业务的影响大小，以及用户希望做什么样的修改。然后由维护组织管理员确认维护类型。
对于改正性维护申请，从评价错误的严重性开始。如果存在严重的错误，则必须安排人员，在系统监督员的指导下，进行问题分析，寻找错误发生的原因，进行“救火”性的紧急维护； 对于不严重的错误，可根据任务、机时情况、视轻重缓急，进行排队，统一安排时间。
对于适应性维护和完善性维护申请，需要先确定每项申请的优先次序。若某项申请的优先级非常高，就可立即开始维护工作，否则，维护申请和其它的开发工作一样，进行排队，统一安排时间。
尽管维护申请的类型不同，但都要进行同样的技术工作。这些工作有：修改软件需求说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试( 回归测试)、确认测试、软件配置评审等。
在每次软件维护任务完成后，最好进行一次情况评审，确认：在目前情况下，设计、编码、测试中的哪一方面可以改进？哪些维护资源应该有但没有？工作中主要的或次要的障碍是什么？从维护申请的类型来看是否应当有预防性维护？
(3) 维护评价
评价维护活动比较困难，因为缺乏可靠的数据。但如果维护记录做得比较好，就可以得出一些维护“性能”方面的度量值。可参考的度量值如：
每次程序运行时的平均出错次数；
花费在每类维护上的总“人时”数；
每个程序、每种语言、每种维护类型的程序平均修改次数；
因为维护，增加或删除每个源程序语句所花费的平均“人时”数；
用于每种语言的平均“人时”数；
维护申请报告的平均处理时间；
各类维护申请的百分比。
这七种度量值提供了定量的数据，据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。因此，这些数据可以用来评价维护工作。
4. 程序修改的步骤及修改的副作用
(1) 分析和理解程序
经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面， 软件的可理解性和文档的质量非常重要。必须：
理解程序的功能和目标；
掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、 控制结构、数据结构和输入／输出结构等；
了解数据流信息，即所涉及到的数据来源何处，在哪里被使用；
了解控制流信息，即执行每条路径的结果；
理解程序的操作(使用)要求；
为了容易地理解程序，要求自顶向下地理解现有源程序的程序结构和数据结构，为此可采用如下方法：
① 分析程序结构图：
分析各个过程的源代码，建立一个直接调用矩阵D或调用树。
建立过程的间接调用矩阵。
分析各个过程的接口，估计更改的复杂性。
② 数据跟踪
建立各层次的程序级上的接口图，展示各模块或过程的调用方式和接口参数；
利用数据流分析方法，对过程内部的一些变量进行跟踪；维护人员通过这种数据流跟踪，可获得有关数据在过程间如何传递，在过程内如何处理等信息。
③ 控制跟踪
控制流跟踪同样可在结构图基础上或源程序基础上进行。可采用符号执行或实际动态跟踪的方法，了解数据如何从一个输入源到达输出点的。
④ 在分析的过程中，充分阅读和使用源程序清单和文档，分析现有文档的合理性。
⑤ 充分使用由编译程序或汇编程序提供的交叉引用表、符号表、以及其它有用的信息。
⑥ 如有可能，积极参加开发工作。
(2) 修改程序
对程序的修改，必须事先做出计划，有预谋地、周密有效地实施修改。
① 设计程序的修改计划
程序的修改计划要考虑人员和资源的安排。修改计划的内容主要包括：
规格说明信息：数据修改、处理修改、作业控制语言修改、系统之间接口的修改等；
维护资源：新程序版本、测试数据、所需的软件系统、计算机时间等；
人员：程序员、用户相关人员、技术支持人员、厂家联系人、数据录入员等；
提供：纸面、计算机媒体等。
针对以上每一项，要说明必要性、从何处着手、是否接受、日期等。通常，可采用自顶向下的方法，在理解程序的基础上，
ⅰ) 研究程序的各个模块、模块的接口、及数据库，从全局的观点，提出修改计划。
ⅱ) 依次地把要修改的、以及那些受修改影响的模块和数据结构分离出来。为此，要
识别受修改影响的数据；
识别使用这些数据的程序模块；
对于上面程序模块，按是产生数据、修改数据、还是删除数据进行分类；
识别对这些数据元素的外部控制信息；
识别编辑和检查这些数据元素的地方；
隔离要修改的部分；
ⅲ) 详细地分析要修改的、以及那些受变更影响的模块和数据结构的内部细节，设计修改计划，标明新逻辑及要改动的现有逻辑。
ⅳ) 向用户提供回避措施。用户的某些业务因软件中发生问题而中断，为不让系统长时间停止运行，需把问题局部化，在可能的范围内继续开展业务。可以采取的措施有：
在问题的原因还未找到时，先就问题的现象，提供回避的操作方法。
如果弄清了问题的原因，可通过临时修改或改变运行控制以回避在系统运行时产生的问题。
② 修改代码，以适应变化
正确、有效地编写修改代码；
要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令；
不要删除程序语句，除非完全肯定它是无用的；
不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应自行设置自己的变量；
插入错误检测语句；
在修改过程中做好修改的详细记录，消除变更中任何有害的副作用(波动效应）；③ 修改程序的副作用
所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况，有三种副作用：
修改代码的副作用。在使用程序设计语言修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、 删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率，以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时，都容易引入错误。
修改数据的副作用。在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如，在重新定义局部的或全局的常量、 重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小、修改全局或公共数据、重新初始化控制标志或指针、重新排列输入／输出或子程序的参数时，容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。在此文档中描述了一种交叉引用，把数据元素、记录、文件和其它结构联系起来。文档的副作用。对数据流、软件结构、 模块逻辑或任何其它有关特性进行修改时，必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配，缺省条件改变，新错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说，软件事实上就是文档。如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。例如，对交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。过时的文档内容、索引和文本可能造成冲突，引起用户的失败和不满。因此，必须在软件交付之前对整个软件配置进行评审，以减少文档的副作用。
为了控制因修改而引起的副作用，要做到：
ⅰ) 按模块把修改分组；
ⅱ) 自顶向下地安排被修改模块的顺序；
ⅲ) 每次修改一个模块；
ⅳ) 对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用。可以使用交叉引用表、存储映象表、执行流程跟踪等。(3) 重新验证程序
在将修改后的程序提交用户之前，需要用以下的方法进行充分的确认和测试，以保证整个修改后的程序的正确性。
① 静态确认
修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序至少需要两个人参加。要检查
修改是否涉及到规格说明? 修改结果是否符合规格说明? 有没有歪曲规格说明?
程序的修改是否足以修正软件中的问题? 源程序代码有无逻辑错误? 修改时有无修补失误?
修改部分对其它部分有无不良影响(副作用)?
对软件进行修改，常常会引发别的问题，因此有必要检查修改的影响范围。
② 计算机确认
在充分进行了以上确认的基础上，要用计算机对修改程序进行确认测试：
确认测试顺序：先对修改部分进行测试，然后隔离修改部分，测试程序的未修改部分，最后再把它们集成起来进行测试。这种测试称为回归测试。
准备标准的测试用例。
充分利用软件工具帮助重新验证过程。
在重新确认过程中，需邀请用户参加。③ 维护后的验收──在交付新软件之前，维护主管部门要检验：
全部文档是否完备，并已更新；
所有测试用例和测试结果已经正确记载；
记录软件配置所有副本的工作已经完成；
维护工序和责任已经确定。
