软件产品维护阶段的缺陷问题管理

姜 文，刘立康

(西安电子科技大学 通信工程学院，陕西 西安 710071)

软件产品维护阶段的缺陷问题管理

姜 文，刘立康

(西安电子科技大学 通信工程学院，陕西 西安 710071)

软件产品维护阶段的缺陷问题管理对于客户和企业都是一项十分重要的工作。缺陷问题管理就是对问题单进行管理，结合问题单管理，介绍了在软件产品维护工作链和各种软件技术问题的来源，详细叙述了三种软件产品缺陷问题管理系统和三种软件产品缺陷问题单的处理流程，包括研发组DTS问题单处理流程、维护组内部问题单处理流程和客户问题管理系统的问题单处理流程。对软件缺陷问题的处理层级进行了详细分析。最后介绍了一些典型维护工作案例。长期的工作实践表明，问题单管理有利于企业高层了解客户方反映的软件产品存在的各种缺陷问题，有利于软件维护人员共同协作做好软件产品维护工作，及时处理解决各种软件缺陷问题，提高软件产品的维护工作效率，同时也有助于促进软件产品新版本的开发。

客户问题管理系统；缺陷跟踪系统；问题单；运维工程师

0 引 言

软件维护[1-3]作为软件生命周期的最后一个环节，是软件产品生命周期中持续时间最长的阶段，在软件开发完成并交付给客户方使用后，需要持续为客户提供高质量的软件产品维护工作。市场竞争加剧和企业规模的不断扩大给现代企业提出了新的挑战。企业不仅需要提供好的产品，还需要满足客户越来越挑剔的服务；企业在发展到一定规模后需要加强对客户服务的投入。市场是有限的，但是服务是无限的，做好产品的维护工作是服务的主要内容之一。

软件产品维护阶段的缺陷问题管理，就是对缺陷问题单的管理。问题单系统适合于企业产品维护工作链使用。将客户方提出的问题抽象成问题单的形式，以问题单为载体，使问题信息在客户方,维护组和研发组之间尽可能无失真地传输。借助互联网平台，使信息交互更加方便快捷，提高运维团队的反应能力，大大提高了企业产品维护工作的效率。

文中介绍了软件产品维护工作链和软件技术问题来源，叙述了三种软件产品缺陷管理系统和三种软件产品缺陷问题单的处理流程。对软件缺陷问题的处理层级进行了详尽分析，最后介绍了一些典型维护工作案例。

1 软件产品维护工作链和技术问题来源

软件产品在其生命周期中通常有许多版本，需要不断进行产品版本的更新升级，需要做好产品维护工作，提高产品维护的效率与质量。

1.1 软件产品的版本升级过程

软件产品进入市场是指该产品的某个版本的软件产品进入市场，软件产品交付客户使用后，该版本软件产品即进入维护阶段。为了解决客户方在软件使用过程中的缺陷问题，需要软件维护组不断推出补丁版本。软件产品维护实际上是对某个软件产品特定版本的维护。通常经过多个补丁版本后，根据技术的发展，客户方对功能扩展的要求，结合补丁版本改进的技术问题推出软件产品新版本。

1.2 软件产品维护工作链

对于软件产品来说，整个维护工作链[4-6]可以分为三块：客户方、软件产品维护组、软件产品新版本研发组。

软件产品维护阶段的相关单位如图1所示。

图1 软件产品维护阶段的相关单位

1)客户方：包括客户局点(软件产品用户)和售后服务和技术支持组。由于客户局点通常通过售后服务部门反映各种技术问题，售后服务技术部门可以看作各客户局点的代言方。客户局点也可以直接反映问题。

(1)软件产品客户：软件产品的购买和使用者，一个软件产品通常有多个客户。

(2)售后服务和技术支持组：通常属于产品销售部门，负责产品的演示、安装和用户培训，负责处理软件产品常见的一些技术问题。

2)软件产品维护组：负责处理各客户局点软件产品使用阶段的各种软件缺陷问题。与研发组合作开发软件产品当前版本的补丁版本。维护组有专用的实验设备，可以作为实验环境安装运行当前版本的软件产品，维护组的成员不仅熟悉该软件的功能和运行环境，而且也要熟悉该软件的内部程序结构和各种相关文档。维护组通常为多个客户方局点提供软件产品的维护和技术支持。

3)软件产品新版本研发组：负责新版本研发，包括补丁版本和升级的新版本。

软件产品的使用、维护和版本更新这三者之间需要相互促进，良性互动才能使软件产品获得健康发展，使软件产品的性能和功能得到不断提升。

1.3 维护阶段软件产品技术问题来源与分类

软件产品使用过程中提出的技术问题分为两类：软件缺陷问题和软件产品改进提升的问题。软件产品维护阶段的技术问题的来源如图2所示。

图2 维护阶段软件产品技术问题分类图

(1)圆1：上方的圆表示客户方技术问题，通常这些问题是客户局点和售后服务技术支持组提出的。

(2)圆2：右下方的圆表示软件产品维护组提出的技术问题，包括客户提交维护组的问题以及维护组在产品维护过程中发现的问题。

(3)圆3：左下方的圆表示软件产品新版本研发组提出的问题，根据技术发展、环境变化和客户要求提出的软件产品功能扩展和性能提升的诸多技术问题。

(4)圆1与圆2的交集：客户方提交到维护组的软件缺陷问题。

(5)圆1与圆3的交集：客户方和销售部门反馈给研发组的软件产品需要改进提升的问题。

(6)圆2与圆3的交集：维护组与研发组共同处理的软件代码缺陷问题以及其他问题。

(7)三个圆的交集：客户方提交到维护组的软件缺陷问题，维护组与研发组共同处理。

2 软件产品在维护阶段的缺陷问题管理

软件产品维护阶段的缺陷问题管理，就是对问题单的管理。问题单系统适合于软件产品维护工作链使用，将各种复杂的问题提取出共性，抽象成问题单的形式，并以问题单为载体，使问题信息在客户方、维护组和研发组之间无失真地传输。通过问题单管理，管理整个软件产品维护工作。

2.1 软件产品缺陷问题管理系统

软件产品的维护过程中，软件产品缺陷问题管理需要用到三个管理工具[7-10]，分别是企业的客户问题管理系统、维护组的软件缺陷管理系统和研发组的软件缺陷跟踪系统。

2.1.1 客户问题管理系统

客户问题管理系统(Customer Request Management System，CRMS)属于客户关系管理的范畴。它是企业提供产品售前、售后服务及管理客户问题的平台。CRMS处于企业下游的服务层，主要负责客户需求的反馈、跟踪和实现；客户问题的处理、安抚，客户服务的主动或者被动的相关行为。客户问题管理系统是企业重要的管理系统之一，系统通过企业网站为国内外客户提供各种问题的输入接口。企业通过该系统受理、记录、跟踪、解决所有的客户问题。客户问题管理系统以问题单为主线，问题单管理包括创建问题单和查询问题单，把问题单分发给相关人员处理，问题处理完毕后，将处理结果反馈给客户。客户对处理结果满意，关闭提交的问题单。

软件产品客户方在该系统上挂单提交各种技术问题和软件产品使用中的缺陷问题。相应软件产品的维护组经理负责处理问题单中的软件产品缺陷问题。研发组的负责人也可以查询软件产品的各种技术问题，以便更好地研发软件产品新版本。

该系统是一套综合的企业产品运维体系解决方案，能够有效提升企业运维效率，提升产品市场竞争力，并能在使用中持续为企业积累宝贵的智力资源。

2.1.2 维护组缺陷管理系统

在如今激烈的市场竞争环境下，一款软件产品能够长期生存下来为企业创造利益，必然需要有一个专业高效的维护团队持续为该产品提供有力的技术支持。维护组的内部技术管理十分重要，有助于提高维护工作效率。

维护组内部使用的缺陷管理系统是BugFree软件[11]。BugFree工具是借鉴微软的软件研发流程和软件缺陷管理理念，将PHP与MySQL结合起来开发的软件缺陷管理系统，是众多软件缺陷管理系统中相对简单实用并且开放源免费的一种缺陷管理系统。BugFree适用于中小型软件企业，大型软件企业的各部门、小组、各种技术开发小组或者团队。维护组通过BugFree管理日常维护工作，通过在BugFree提单的方式组织安排软件产品的维护工作。

2.1.3 缺陷跟踪系统

缺陷跟踪系统[12-15]是软件项目开发管理系统的一部分，主要是跟踪处理软件源代码的各种缺陷(bug)。项目经理可以通过缺陷跟踪系统了解软件代码缺陷的处理情况，定期获得最新的缺陷问题报告。软件代码缺陷问题发现后，需要在该系统上提单(DTS问题单)，测试经理组织测试工程师对每一个缺陷在实验室环境上重现，分配给开发人员处理解决该缺陷问题，对每一个缺陷进行提单跟踪。软件代码缺陷修复后，关闭DTS问题单。

2.2 三种软件产品缺陷管理系统的比较

软件产品在维护过程中,三种系统通过问题单处理流程联系在一起。三种系统的比较如表1所示。

表1 三种系统的比较

3 三种软件产品缺陷问题单的处理流程

3.1 研发组DTS问题单处理流程

对于软件产品源代码缺陷，通常针对多个缺陷出补丁包版本一起修复。维护组经理制定补丁计划之后，测试经理组织测试工程师对每一个缺陷在实验室环境上重现，并在研发组缺陷跟踪系统中对每一个缺陷进行提单跟踪。分配软件开发人员编写代码修复这些缺陷，通常维护组的运维人员也参与这项工作。补丁包制作完成后，测试经理组织测试工程师进行统一测试，确认各个软件缺陷已经解决了，然后关闭各个软件缺陷的DTS问题单。DTS问题单的处理流程如图3所示。

维护组通常需要定期发布补丁版本，修复多个软件缺陷。对于一些需要紧急处理的软件源代码缺陷也可以单独出补丁版本。

图3 研发组DTS问题单处理流程

3.2 维护组BugFree问题单处理流程

维护组的软件缺陷问题来源于两个地方：

(1)维护组运维人员登录企业的客户问题管理系统，查询本维护组负责维护的软件产品客户方提交的缺陷问题。

(2)维护组运维人员在软件产品的维护过程中发现的各种缺陷问题，需要进行自主处理。

软件产品缺陷问题分为两类：

(1)非软件代码缺陷。排除缺陷不需要修改代码，通常包括软硬件不兼容，软件设置不正确，硬件设置不正确，软件产品安装和使用不规范等导致的工作问题。维护组可以独自处理。

(2)软件代码缺陷。需要修改软件代码，需要维护组和研发组合作处理。

维护组缺陷问题单处理流程如图4所示。

图4 维护组问题单处理流程

3.3 客户问题管理系统ICARE问题单处理流程

客户局点的软件产品出现各种缺陷或问题时，客户局点通常将缺陷或问题反馈给软件产品售后工程师，由售后工程师在客户问题系统中提单。客户缺陷问题单处理流程如图5所示。

4 软件缺陷问题处理层级分析

4.1 维护阶段软件产品缺陷问题来源

软件产品维护过程中，各种缺陷问题通常来源于以下几方面：

(1)各客户局点软件产品在使用过程中发现的各种缺陷问题和提出的特殊要求；

(2)维护组运维工程师在维护工作中发现的软件缺陷问题；

图5 客户缺陷问题单处理流程

(3)测试工程师在日常测试过程中发现的各种软件缺陷问题；

(4)研发组研发人员在新版本研发过程中发现当前版本存在的问题。

4.2 软件产品缺陷问题单的层级图

由维护阶段软件产品技术问题分类图(见图2)可以得到软件产品缺陷问题层级图，如图6所示。

图6 软件产品缺陷问题层级图

根据该图，软件产品缺陷问题分为三个层级。左方的圆表示客户方在软件使用过程中遇到的缺陷问题，中间的圆表示软件产品维护组在软件维护过程中遇到的缺陷问题，右方的圆表示研发组在软件维护过程在需要处理的问题。圆重叠的区域表示几方合作处理的缺陷问题。

4.3 客户方软件缺陷问题处理层级

客户方软件缺陷问题处理可以分为三个层级：

(1)软件缺陷问题由售后服务工程师(通常称为一线工程师，现场工程师)处理解决的问题。通常是一些常见的技术问题，通常不在客户问题管理系统上提单。位于图6中区域1。

(2)软件缺陷问题由维护组运维工程师(通常称为二线工程师)处理解决的问题。客户方在客户问题管理系统上提单，位于图6中区域2，处理此类问题需要经过两个问题单。

(3)软件缺陷问题由研发组工程师(通常称为三线工程师)和运维工程师合作处理解决的问题。这类问题通常属于软件代码缺陷问题，需要出补丁包才能解决。客户方在客户问题管理系统上提单，位于图6中区域3，处理此类问题需要经过三个问题单。

4.4 软件产品维护工作链中各方的作用

4.4.1 售后服务工程师在软件产品维护过程中的作用

售后服务工程师通常属于软件产品销售部门，在软件产品维护过程中需要做以下工作。

(1)负责用户培训，软件产品安装和调试，解决一些日常的技术问题。

(2)对于疑难问题协助客户方在客户问题管理系统上提单，配合维护组解决软件缺陷问题。安装调试软件补丁版本，指导用户使用。

(3)配合销售部门进行市场调研，了解客户对软件产品的改进和功能扩展要求，为新版本研发组提供各种相关信息和资料。

4.4.2 维护组在软件产品维护过程中的作用

维护组在软件维护过程中位于中间位置，在软件产品维护过程中起着核心作用。

(1)处理客户方提出的各种问题，有时运维工程师需要亲自到客户现场处理技术问题。

(2)制定补丁计划；定期发布产品补丁版本，在研发组的协助下处理软件产品源代码缺陷问题，负责补丁版本的版本管理工作。

(3)对于软件产品出现问题较多的模块，对该模块的源代码进行排查，进行自主改进。

(4)对于软件产品非源代码缺陷问题，安排资料工程师对软件产品文档的添加新增FAQ(Frequently Asked Questions)，定期安排售后工程师与客户方人员进行产品培训。

(5)软件缺陷问题处理完毕后，维护经理安排文档人员汇编相关资料，将处理结果作为案例放入案例库，供以后软件维护和新版本研发参考。为售后服务工程师和研发组提供相关的文档资料。

4.4.3 研发组在软件产品维护过程中的作用

研发组负责软件产品新版本开发，其优势在于对软件产品源代码和程序架构十分熟悉。

(1)协助维护组制作产品补丁包，而且要处理补丁代码和软件产品其他代码的兼容性问题。对于比较大的复杂补丁模块，研发组开发人员需要亲自编写源代码处理补丁问题。

(2)在开发新版本的过程中发现当前版本需要改进的问题，提供给维护组加入补丁包。

(3)研发组在程序设计方面具有优势，但是开发新版本也要了解客户方的各种技术问题，了解软件维护过程中各种缺陷问题处理，特别需要熟悉各个补丁版本。

5 典型案例

5.1 非软件代码问题导致的缺陷

缺陷问题描述：某客户局点M由于软件系统管理员工作交接不彻底，导致软件系统管理员账号密码丢失，新管理员多次输入错误的管理员密码，导致管理员账号被锁定，无法登陆系统，导致系统无法正常使用。严重程度：高。

缺陷问题的处理过程如下：

(1)售后工程师在客户问题管理系统提单(ICARE单)。

(2)维护组查询到该问题单，维护经理分配给某运维工程师处理，运维工程师在与售后工程师了解到问题现象后，在维护组的实验环境重现出这一现象，在维护组的缺陷管理系统中提单(BugFree单)。

(3)维护经理指派运维工程师处理该问题单，运维工程师经过分析后，删除原有的密码相关的配置文件，将软件系统的管理员账号恢复默认密码。在项目组的实验室环境反复验证之后，确认此方法可行，运维工程师将解决方案的每个步骤写成操作文档，以邮件形式发给M局点，并将操作文档以附件形式上传维护组缺陷管理系统。

(4)售后工程师协助M局点客户处理该问题，并将处理结果反馈给维护组。运维工程师关闭维护组该问题BugFree单，售后工程师关闭该问题ICARE单。

(5)编写相关文档，将该缺陷问题加入案例库。

之后，又有一个客户局点T也发生了类似问题，另一运维工程师从案例库中找到M局点的案例以及解决方法，高效地解决了该问题。维护经理经过了解发现，客户局点和售后工程师对这类问题不熟悉，于是在定期举行的产品培训中重点培训了这个案例，并将这个案例加入产品文档的FAQ。

5.2 软件源代码导致的缺陷

缺陷问题描述：某局点客户在软件使用过程中发现某些地区的中继群名称不能显示，只能显示一串对应的中继群号。严重程度：高。

缺陷问题的处理过程如下：

(1)售后工程师在客户问题管理系统提单(ICARE单)。

(2)运维项目组查询到该问题单，运维经理分配给某运维工程师处理，运维工程师在与售后工程师了解到问题现象后，在维护组的实验环境重现出这一现象，并在维护组缺陷管理系统中提单(BugFree单)。

(3)维护经理指派运维工程师处理该问题单，运维工程师经过分析后，定位出该问题是软件代码需要改进的缺陷。该软件系统与Oracle 11g配套使用，由于软件系统中一次最多只能获取到2 000条记录，对于大于2 000条记录时只能取到2 000条处，从而导致部分中继群名称不能被取到并显示出来。由于通信规模的发展，获取的记录数大于2 000条，运维工程师提出的解决方案是，先获取中继群号相关数据表的总数据条数，再使用循环读取的方法来解决问题。需要修改源代码，制作软件补丁。将该问题加入补丁包计划。

(4)维护经理制定补丁包计划后，测试经理组织测试工程师对每一个缺陷在实验室环境上重现，并在研发组缺陷跟踪系统中对每一个软件缺陷进行提单(DTS单)。

(5)补丁包制作完成后，测试经理组织测试工程师进行统一测试，确认各个软件缺陷已经解决了，然后关闭各个软件缺陷的DTS问题单。

(6)售后工程师协助该局点客户处理该问题，安装使用软件产品的补丁版本，确认问题解决后，并将处理结果反馈给维护组。运维工程师关闭维护组该问题BugFree单，售后工程师关闭该问题ICARE单。

(7)编写相关文档，将该缺陷问题加入案例库。

工作实践表明，软件产品维护阶段的缺陷问题管理十分重要，做好此项工作有助于企业高层了解客户方反映的各种软件产品缺陷问题，了解问题解决的状况。同时也有利于软件维护人员相互协作，及时处理解决各种软件缺陷问题，提高软件产品缺陷的解决效率。

6 结束语

软件产品的维护管理，是指企业采用相关的方法、手段、技术、制度、流程和文档等，对软件产品维护工作进行的综合管理。软件产品维护阶段的缺陷问题管理对于企业和客户方都十分重要。问题单系统的引入，可以提高企业产品维护的工作效率，增强企业产品的市场竞争力。随着计算机信息技术的不断发展，需要进一步研究企业产品的维护管理。对这一领域的研究和探索，将具有广阔的发展前景和重要的现实意义。

[1]PfleegerSL,AtleeJM.软件工程[M].杨卫东,译.第4版.北京：人民邮电出版社，2010.

[2]GrubbP,TakangAA.软件维护：概念与实践[M].韩 柯，孟海军,译.第2版.北京：电子工业出版社,2004.

[3] 于 波，姜 艳.软件质量管理实践—软件缺陷预防、清除、管理实用方法[M]．北京：电子工业出版社，2008.

[4] 姜 文，刘立康.现代应用软件的维护与技术支持[J].计算机技术与发展，2015，25(4)：116-120.

[5] 姜 文，刘立康.应用软件维护中的补丁开发与管理[J].计算机技术与发展，2015，25(11)：11-16.

[6] 姜 文，刘立康.Oracle数据库补丁问题研究[J].电子设计工程，2014，22(20)：10-13.

[7] 杨 锐.基于Cocoon的客户问题管理系统设计与实现[D].北京：北京工业大学,2008.

[8] 张 亮.H公司客户问题管理模式与信息系统设计研究[D].成都：电子科技大学,2010.

[9] 张亚博.网上问题单系统的设计与实现[D].北京：北京邮电大学,2009.

[10] 权 衡.基于Web的软件缺陷管理系统的设计与实现[D].武汉：华中科技大学,2014.

[11] 汤 杰.基于Bugfree的银行业务软件测试设计与实施[D].成都：电子科技大学,2013.

[12]ShahR.Oracleondemandbestpractices:criticalpatchupdate[R].[s.l.]:OracleCorporation，2008.

[13]MehdiG.Contributorstoqualityduringsoftwaremaintenance[J].DecisionSupportSystems,1998,23(4):361-369.

[14]PfleegerSL,AtleeJM.Softwareengineering:theoryandpractice[M].NewJersey:Prentice-Hall,Inc,2006.

[15]HarryMS,AneconGH,ViennaA.Acostmodelforsoftwaremaintenance&evolution[C]//Internationalconferenceonsoftwaremaintenance.[s.l.]:IEEE,2004:6763-6773.

Defects Management of Software Products in Maintenance Phase

JIANG Wen，LIU Li-kang

(School of Telecommunication Engineering,Xi’dian University,Xi’an 710071,China)

The management of defect in the process of software maintenance is a very important work for both customer and enterprise.The management of defect is administering the problem report.Combined with the management of problem report,the software maintenance work chain and the source of software technical problems are introduced,detailed description of three systems of the software defect management and three processes of software defect problem report,including the process of DTS problem report in development group,the process of problem report inside the maintenance group,the process of problem report to customer’s problem management.It is careful analysis of the processing level of software defect.Finally,some typical maintenance work cases are introduced.Long-term practice shows that problem report management is beneficial to executives to understand all kinds of faults in software which are reflected by customers and to maintenance engineer to work together for doing good job in software maintenance,improving the efficiency of the maintenance to software,also promoting the new version of the software development.

customer problem management system;defect tracking system;problem report;operation and maintenance engineer

2016-03-05

2016-06-15

时间：2016-11-22

国家部委基础科研计划：国防预研基金项目(A1120110007)

姜 文(1986-)，女，工程师，硕士，CCF会员，研究方向为图像处理与分析、数据库应用和软件工程；刘立康，副教授，研究方向为数字通信、图像传输与处理、图像分析与识别等。

http://www.cnki.net/kcms/detail/61.1450.tp.20161122.1227.016.html

TP311.53

A

1673-629X(2016)12-0035-06

10.3969/j.issn.1673-629X.2016.12.038