基于配置管理的软件维护性评估*

郝学良，朱小冬，叶飞

（军械工程学院，石家庄050003）

基于配置管理的软件维护性评估*

郝学良，朱小冬，叶飞

（军械工程学院，石家庄050003）

对软件质量进行定量化管理是软件工程领域的趋势，也是软件质量保证的重要手段。针对软件维护性定量评估难、数据获取难的问题，分析了软件维护性受配置管理关键要素的影响，提出利用配置管理数据对软件维护性间接评估的方法。结合软件工程开发实际，建立了配置管理数据收集过程，利用维护时间作为参数，统计5类功能点维护时间对软件维护性进行度量，实现了软件维护性的定量评估，并利用实际项目对方法的可行性和有效性进行了验证。

软件配置管理，维护性评估，功能点维护时间，数据收集

0　引言

调查表明，软件生命周期费用的66%花费在了维护阶段［1］，降低软件维护费用成为软件工程的基本目标之一［2］。面对对象开发技术（OOP）借助对象的封装和继承技术提高了软件组件化代码的可复用性，一定程度上提高了软件可维护性，但是软件维护的负担依然沉重［3］。

McCall等人定义了一种软件质量层次结构，对软件可维护性进行了分解，并对各子特性提出了相应的度量准则，但是对可维护性的直接测度仍然困难［4］。ISO/IEC 9126-1（2001）将软件可维护性分解为易分析性、易改变性、稳定性和易测试性4个子特性，并分别从内部属性、外部属性和使用属性3个维度对软件维护性度量进行了分析，其本质上仍是定性评价［5］。Fenton通过对软件本身复杂度试图进行定量度量，为软件维护性的评估提供了依据，但是关于软件复杂度的定义仍有待进一步研究［6］。Bettenburg和Hassan从社会性因素考虑分析了人员交互对于软件维护性影响，对传统的基于代码的度量进行了补充［7］。Calikli和Bener通过实例验证了认知偏见对软件缺陷形成的影响，从认知科学角度对软件可维护性预测提供了新思路［8］，但是认知偏见在软件工程实践中的复现和验证仍是难题。软件可维护性评估的目的是提高和控制软件项目的可维护性，定量化是实现这一目的的关键途径，而直接的量化度量又面对测不准或不可测的困境，因此，本文通过分析配置管理对软件维护性影响，利用软件配置管理数据来对软件维护性表现进行间接度量，从而实现维护性定量评估的目的。

1　软件配置管理对软件维护性的影响

软件项目管理对于提高软件维护性具有重要意义，项目数据收集是项目定量管理的基础，也可以作为软件维护性评估的基础。软件开发过程是一个非常复杂并且难以预测的过程，同时，软件开发过程和软件维护过程之间存在一定的对应关系。当前很多软件项目的开发和维护是交叉的，很多时候可以说开发人员同时又是维护人员［9］。

科学的软件项目管理可将开发人员的个人能力转化为团队的能力，是解决软件开发难题的有效方式。过程数据是软件工程组织能够洞悉已有过程的功效（如软件工程任务、工作产品及里程碑），它们使得项目管理者和开发者能够评估哪些部分可以运作，哪些部分不行。在关于项目管理的讨论中，Meiler Page-Jones提到，没有良好的项目管理，会导致项目人员徒劳地与噩梦般的项目斗争着，在最后期限的压力下挣扎，在软件交付后又继续花费大量时间去维护［10］。软件项目管理不仅是保证软件按时交付的基础，同时也对软件维护性具有极大的影响。

1.1软件配置管理的关键要素

1.1.1行政管理

人是决定软件项目成败的关键因素［11］，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素［12］。软件开发是一项对智力要求极高的活动，需要将人的创造力发挥出来。同时，人为因素的自由度过大，又会造成混乱和冲突。项目管理应该激发人员的创造力和责任心，同时最大限度地降低混乱。军用软件作为专业性较强的行业软件，对于人员的要求更需要有较强的纪律性。

1.1.2变更管理

软件开发的特点是需求变更频繁，人员流动性强，这是导致软件产品质量差，维护困难的症结所在。同时，变更又是普遍性的，没有变更，便没有任何软件产品。配置管理通过系统地对配置项的变更进行管理，特别是对软件文档的变更管理，保证在整个生命周期内配置项的完整性和可跟踪性。

1.1.3进度管理

在众多软件项目中，缺乏合理的进度安排是项目滞后的主要原因［12］。有效的进度管理利于增强项目成员的紧迫感，保证项目在规定期限内完成。

1.1.4Bug追踪

Bug追踪管理是提高软件质量节约开发成本的重要手段。没有良好的Bug追踪管理会导致软件项目质量、成本和人力资源的失控，甚至导致项目失败。

1.2人员编程风格对代码可维护性的影响

软件维护与硬件维护不同的是，硬件故障一般来源于物理退化，而软件故障大部分是人为引入的逻辑错误，所以软件可理解性是影响软件维护工作量的主要因素。通常维护人员几乎一半的时间都花在了对软件代码和文档进行研究，以达到理解程序的目的［13］。代码质量与人员的技术水平、责任心有直接关系。源代码的算法控制结构、数据结构包括编程风格构成源代码维护性影响因素的3个重要维度［14］。优秀的人员开发的代码具有良好的维护性，主要表现为：①可读性：可读性是软件代码质量很重要的一方面，维护性好的代码首先应该是可读的、可理解的。②模块化：模块之间应是高内聚、松耦合的，可以避免波及效应的产生；③可测性：代码必须为测试提供便利，且代码必须包含完备的测试代码。

高质量的代码可以很容易地为维护人员所理解、分析和改正，从而使维护性得到提高。

1.3进度管理对软件维护性的影响

数据是反映质量的客观证据，是质量属性的母体。项目进度管理中可以产生大量数据。因此，进度管理数据客观反映了软件开发的过程。在软件开发过程中，开发语言、平台、应用程序以及工具使用之类的变量都是影响软件项目成本、工期和效率的重要因素。考虑到软件开发与软件维护过程的相似性，同样地，这些变量和数据也会对软件维护性产生直接影响。项目管理数据正是这些变量信息的集合，从中可以提出反映软件维护性水平的根本要素。

维护进度管理数据是项目维护的历史，通过回顾这些数据，可以对项目的进程进行校正。当出现大的偏差时及时对项目进行控制。

1.4配置管理对软件维护性的影响

配置管理是CMMI评估中的首要过程域，是软件开发的“保险柜”、“岩钉”和“脚印”［15］。在软件开发和维护过程中采用严格配置管理，可使得软件过程能力稳定改善。对于一些小型项目，虽然采取了一些配置管理的工具，如CVS和SVN，但是没有能够建立起严格的基线理念。表1所示为两个规模相当的小型项目的维护数据，其中项目A实施了严格的配置管理过程，并严格建立基线；项目B没有建立严格基线，从表中可以看出项目A在后续版本中，维护成本明显降低。

表1　配置管理对软件维护成本的影响

1.5Bug追踪对软件维护性的影响

Bug清除和修复是软件维护的一项重要内容，对Bug进行有效跟踪和管理可以更好地控制Bug的产生和转移，避免Bug的再生和重复维护。

综上，有效的软件项目管理可以提高软件维护性，项目管理数据反映了软件维护性的高低。

2　配置管理数据收集过程

Whitmire［16］认为，评价软件设计好坏的基础是数据收集和度量，同样软件维护性评估的准基础也是数据。采用真实的软件项目数据，可以从中提取宝贵的软件维护性信息，解释当前软件项目的维护性状态，并从中发现需要注意的问题。数据度量可以作为一种强有力的维护性设计与控制工具。从战略、战术、技术任意一个层面出发，都可以构建稳定的维护性度量体系，作为软件维护性度量的强有力工具。

配置管理数据可以通过项目任务分配跟踪报表、项目管理工作日志以及项目管理里程碑跟踪报告等途径进行采集。数据收集完成之后，选择适当的统计方法，选择特定的变量，创建新变量、删除异常值、检测混淆的变量、选择基准分类变量并处理有价值的观察资料，可以实现软件维护性定量度量并帮助在软件开发过程中作出决策。项目管理数据收集流程如图1所示。

图1　配置管理数据收集过程

2.1配置管理数据定义

在技术层面，软件项目管理数据可以从产品的外部属性和内部属性两方面进行考虑。软件维护性是一种外部属性，体现在维护工时、维护工作量等维护服务的外部表现当中。定性地维护评价方法可通过一个小型质量检查表来实现，参与者表达他们关于结构方面的的看法和评价，包括维护任务中和实际的软件属性进行比较，但是这会受评价人员主观经验影响较大。量化地评价则需要通过数据收集获取。

收集的数据主要分为两类：第1类数据是用于对软件理解、更改、测试所花费的总的工作量，以人-时为单位；第2类数据是更改的代码量［17-18］，如更改程序的文档页数、可执行代码行数、构建测试用例数、测试脚本代码行数、部署所需文件数等。第2类数据在度量标准方面还存在一定模糊地带，最终权衡开发方和用户方的需求，选定以功能点为度量标准。

软件维护性是指程序被修改的容易程度，无法直接度量，因此，可采用间接度量的方法，即面向工作量的度量，工种工作量说明：①工程工种按分析、设计、编码实现（包括单元测试）、测试（集成测试及后续的测试，但不包括所检测试），工程工作量可从里程碑跟踪报表中提取，也可以看作是阶段工作量。②管理工时按过程分，包括需求管理、策划、监控、质量保证、配置管理、培训（包括组织级和项目级）、评审。③过程管理工时。过程管理工时和管理工时都可以从子任务工作量报表和月实际工作量报表中提取，并可以对阶段工作量数据进行验证。

2.2配置管理数据采集方法

软件项目管理数据的主要来源是配置管理数据库。在软件工程实践中，这些数据往往庞杂繁乱。配置管理贯穿于软件开发整个过程，对变更过程进行标识、控制、报告和审计。根据配置管理特点，结合变更请求和变更执行两方面对项目变更数据进行采集。

变更请求（ChangeRequest，以下简称CR）是执行变更过程的蓝图，当一次变更请求被批准后，变更过程的执行表现为CR指导下的一系列修改和测试活动，CR的状态转换包括以下步骤：①初始化：明确变更的状态标识和优先级。②修改：执照CR的内容进行代码更改。③完成：按照CR要求完成代码更改。④测试：对更改过的代码进行回归测试。⑤评审：审核变更是否符合CR要求。⑥发布：一次CR的更改完成。

使用配置管理数据库进行维护性数据采集是一种实用性强，可与各种编程环境结合使用的有效方法。度量程序通过分析CR文件就可以完成维护性数据收集难题，减少工作量。

3　实例分析

收集了我单位“美腾”软件开发中心自2010年至2014年4年内开发的4个业务复杂度相近、规模相当，基于相同的语言和开发平台的软件项目，其管理工时占比率和年维护工时数据如表2所示。

表2　软件项目年累积维护工时统计

从表2中看出，管理工时占比多的软件项目其维护工时相应会减少，且每年逞递减趋势。

表3和表4分别给出了美腾开发的两个项目：虚拟维修开发系统和虚拟维修训练系统，按照软件五类功能点里程碑阶段工作量进行数据采集情况如表中所示。

从表3和表4中的数据可以看出，训练系统在分析与设计阶段投入的工作量较大，占38%，开发系统在编码与测试阶段的工作量较大，占59%。据开发人员和用户反馈，开发系统的总体设计结构完善，实行了严格的项目管理，训练系统后期开发人员变化较大，管理也出现了一些漏洞，导致了软件维护性差。从表3和表4的数据中可以看出，配置管理对于软件维护性具有较大的影响。

表3　“美腾”虚拟维修开发系统数据采集（单位：人/时）

表4　“美腾”虚拟维修训练系统数据采集（单位：人/时）

4　结论

软件维护性评估的模型有很多，只有能为开发人员或维护人员提供更多有用信息的模型才对软件开发和生产有意义。本文提出了基于项目管理数据的软件维护性定量评估思想，利用实际项目进行数据收集，通过数据分析对软件维护性进行间接评估。方法可操作性强，具有较强可信性和一定实践价值。同时，方法对数据质量的依赖性较强，在项目管理过程中，应保证数据质量，避免利用数据进行绩效评定。尽量使开发人员感觉不到数据收集的过程，确保数据是帮助开发和项目进展的，从而使开发人员能够主动拥抱数据。

［1］YIP S W L，LAM T.A software maintenance survey［C］//SoftwareEngineeringConference，1994：70-79.

［2］郑人杰.实用软件工程［M］.2版，北京：清华大学出版社，1997.

［3］BANDI R K，VAISHNAVI V K，TURK D E.Predicting maintenance performance usingobject-orienteddesign complexity metrics［J］.IEEE Transactions on Software Engineering，2003，29（1）：77-87.

［4］李金铭.基于McCall模型软件质量的综合评价方法［J］.福建农林大学学报（自然科学版），2005，34（4）：535-538.

［5］常瑞花，贾鹏.基于度量元的静态软件缺陷预测技术［J］.火力与指挥控制，2015，40（2）：1-5.

［6］FENTON N，PFLEEGER S L.Software metrics，a rigorous &practical approach［M］.International Thompson Computer Press，1997：32-36.

［7］BETTENBURG N，HASSAN A E.Studying the impact of social interactions on software quality［J］.Empir Software Eng，2013（18）：375-431.

［8］CALIKLI G，BENER A B.Influenceofconfirmationbiasesof developers on software quality：an empirical study［J］.

SoftwareQual Journal，2013（21）：377-416.

［9］SNEED H M.Measuring the performance of a software maintenance department［C］//Software Maintenance and Reengineering，1997：119-127.

［10］PAGE-JONES，M.Practical project management［M］. DorsetHouse，1985：7-8.

［11］BASILI V R，REITER R W，Jr.An investigation of human factors in software development［J］.Computer，1979：21-38.

［12］布鲁克斯F P.人月神话［M］.汪颖，译.32周年中文纪念版.北京：清华大学出版社，2007.

［13］OMAN P W，COOK C R.Typographic style is more than cosmetic［J］.Communications of the ACM，1990，33（5）：506-520.

［14］ZHUOF，LOWTHER B，OMAN P，etal.Construcitngand testing software maintainability assessment models［C］// Software Metrics Symposium，1993.Proceedings.，First International.Baltimore，MD，1993：61-70.

［15］董越.未雨绸缪：理解软件配置管理［M］.2版.北京：电子工业出版社，2012.

［16］WHITMIRE S.object oriented design measurement［M］. NewYork：JohnWiley&Sons，1997：21-25.

［17］DELIGIANNIS I，STAMELOS I，ANGELIS L，et al.A controlled experiment investigation of an object-oriented design heuristic for maintainability［J］.The Journal of SystemsandSoftware，2004（72）：129-143.

［18］CHEN J C，HUANG S J.An empirical analysis of the impact of software development problemfactors on software maintainability［J］.The Journal of Systems and Software，2009，82：981-991.

Software Maintainability Evaluation Based on Project Management Data

HAOXue-liang，ZHU Xiao-dong，YE Fei
（Ordnance Engineering Academy，Shijiazhuang 050003，China）

Quantitative project management is trend of software engineering，also a way to guarantee software quality.Affect of project management on software maintainability is analyzed and software maintainability evaluation method is proposed based on project management data，aiming at the difficulty of software maintainability quantification.Working time of five kinds of function points，as evaluation parameter，is assembled to evaluate the software maintainability of project.At last，real software project management is used to validate the method，which turns out feasible and effective.

software project management，maintainability evaluation，function point maintenance time，datacollection

TP311.5

A

1002-0640（2016）10-0142-04

2015-08-10

2015-09-11

军队重点预研基金资助项目

郝学良（1984-），男，河北邯郸人，博士生。研究方向：软件保障技术与应用。