基于变更分析的软件开发过程量化系统

盛玉强 杨春花

摘 要： 软件量化对软件项目管理有着至关重要的作用，便于进行开发成本和开发时间的估算，合理规划软件生命周期。目前应用比较广泛的方法大多是以历史经验为基础进行量化管理，由于在过程中存在很多不确定性因素，量化的结果不能准确反映实际情况。考虑到实际开发需求，本文提出一种依据变更数据对软件开发过程进行量化管理的方法，通过对日常变更内容的分析，获取基础数据，进一步建立量化指标，对团队或个人的工作量、效率、活跃度等进行衡量。基于Java EE技术，设计了一个量化管理系统对该方法集中展开研发实现。最后，以Tomcat版本库为例，阐述了具体的实现过程及结果。

关键词： 软件量化；变更分析；过程管理

Abstract：Software quantification plays an important role in software project management which makes it easy to estimate the development cost and development time and reasonably plan the software life cycle. Most of the current methods widely used is based on historical experience to realize a quantitative management because there are many uncertainty factors in the process the quantitative results cannot accurately reflect the actual situation. Considering the actual development requirement this paper proposes a quantitative management method of software development process based on change data which could through the analysis of the daily change of content obtain basic data then establish the quantitative indicators therefore evaluate the team or individual work such as efficiency active measure.Based on the Java EE technology a quantitative management system is designed to implement this method. Finally the implementation process and results of the Tomcat version library are illustrated.

Key words： software quantification；change analysis；process management

引言

軟件度量研究是一个在过去30多年中始终处于发展活跃期的软件工程领域，研究主流是关心软件的品质和软件的定量化度量。

目前行业对软件度量和项目管理的研究，主要集中于对已有度量模型和方法的优化上。如基于IFPUG功能点分析法的改进方法[1]、基于CMMI的量化方法[2-3]、基于Delphi技术对软件规模和进度进行估算的方法[4]、基于偏最小二乘回归的方法校准度量因子，并结合COCOMO模型[5]进行量化的方法[6]、基于GQM模型[7]，利用PUGH矩阵的决策机制进行过程控制和软件量化的方法[8]等。这些方法多以软件的结构为主体提供度量，将软件按照功能点、方法、模块等元素进行拆分后，设置加权参数，实现整体的度量。缺点是只能在软件项目设计阶段进行估算或者在软件开发完成后，对整个项目进行回顾，无法应用到软件开发过程中创建实时的管理，缺乏灵活性。

现有的软件度量方法，可以做到对代码复杂度、每日版本可用率、代码质量缺陷指数[9]等进行度量，但无法做到对变更内容生成定量化分析。为对开发过程定制有效的量化管理，本文提出基于软件开发过程中的变更数据进行量化管理的方法。结合项目开发过程中的具体变更数据，对变更内容进行分析，包括变更的代码行、文档行，变更文件的个数、类型、内容，所属的模块名等统计代码、文档的增、删、改等的操作，建立研究对象的模型。可以根据这些基础数据，对指定时间段内团队效率、活跃度、工作量，成员效率、修改内容、产出量以及文件修改的内容、类型、个数等展开分析，从而调整开发计划，对软件开发过程进行实时调控，实现软件开发过程量化管理。

1 基于变更分析的量化管理方法

1.1 方法概要

现代软件的开发，大多基于版本控制系统。版本控制系统可以支持完备的版本管理功能，用于存储、追踪目录和文件的修改历史。本系统对使用了SVN版本管理系统（Subversion）的软件项目进行分析，首先需要确定软件项目，即SVN仓库，然后对软件开发过程中的变更数据进行获取、分类整理并辅以数据处理后，形成本系统的数据源，由此将有效确保后续数据量化管理系统的设计与实现。研究中，系统设计如图1所示。

其中，数据提取是指从软件版本仓库获取版本变更数据并存储到本地数据库；数据处理是指对抓取到的数据进行过滤优化和分类；软件开发过程量化管理是指对变更数据进行分析、统计、量化，并续接此后的数据可视化和开发过程量化。

1.2 量化管理系统设计

本系统基于SVNKit研发设计。SVNKit是一个Java工具包，用于访问和操作SVN版本库。SVNKit不仅是一个纯Java的SVN类库，而且还适用于主流的绝大多数操作系统，基于SVNKit开发软件，可以实现版本库的管理和信息的获取。

1.2.1 变更数据的获取

基于SVNKit提供的API，使用Java语言开发一套数据获取和管理工具，对变更数据进行获取。获取内容包括：

（1）该软件项目的所有已提交版本。包括版本号、提交者、提交日期、影响的文件名或目录以及注释信息；

（2）所有已提交的版本包含的信息。包括指定版本包含的文件、变更的文件名、变更时间、变更类型等；

（3）所有文件内容。包括文件被增加时的初始内容、变更后的内容，以及文件变更时所对应的版本信息等；

（4）所有文件变更内容。包括文件变更前后对应的版本信息、变更类型、变更内容等；

（5）其它项目信息的获取。包括开发团队、项目相关信息等。

1.2.2 数据分析与处理

对获取到的源数据进行过滤优化和分类。分类方法主要包括：

（1）按文件类型分类。主要区分软件代码和说明文档；

（2）按修改类型分类。主要区分文件的增、删、改操作；

（3）按修改内容分类。主要区分是否为修复bug、执行代码重构、添加测试、添加注释等。

由于获取到的原始数据包含大量冗余数据，并且会产生由于文件名相同、文件内容无法识别、文件编码方式不同等导致的数据异常，所以需要对数据进行优化处理。经数据优化处理后，形成本系统的数据源，用于后期的数据分析和展示，统计变更内容研究。

1.2.3 量化管理

以得到的数据为基础，应用B/S架构、MVC设计模式、MySQL数据库，使用SpringMVC、MyBatis等Java EE后端技术，Ajax、Echarts等前端技术，设计实现量化管理系统，对软件开发过程进行量化管理。

2 系统实现-以Tomcat为例

2.1 选取版本库

本文选取流行的Web应用服务器软件Tomcat的版本库作为数据源。Tomcat是Apache软件基金会（Apache Software Foundation）的Jakarta系统中的一个核心项目，由Apache、Sun 和其它一些公司及个人共同开发而成。由于有了Sun公司的参与和支持，使得最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现，在现代软件开发中提供了业界范本的作用。

Tomcat版本库创建时间为2007年11月10日，截止2017年12月20日，该项目共有26位开发者，5 123个文件，约18 000个提交版本、56 000次文件变更记录，具体可见表1。

2.2 获取变更数据

2.2.1 获取原始数据

基于SVNKit開发版本库数据获取工具，对Tomcat版本库获取版本数据，形成原始数据库。该数据获取工具提供的主要功能如下：

（1）showlogs：获取版本库所有提交版本记录和文件变动记录，记录到数据库的actions表中；

（2）displayFile：获取文件首次提交时的初始内容，用于后续比较变更内容，记录到数据库的contents表中；

（3）showDiff：获取所有内容发生变动的文件列表，记录到数据库的diffs表中；

（4）getHunks：获取所有文件变更内容的具体变更片段，记录到数据库的hunks表中。

2.2.2 数据处理

获取原始数据后，由于对变更分析的需要，需要对数据进行进一步加工处理。内容阐释如下：

（1）根据版本信息，提取版本对应的提交者，存储到user表；

（2）根据版本信息，提取所有版本的版本号相关信息，存储到revisions表；

（3）根据文件首次提交的信息，提取项目中所有的文件信息，存储到files表；

（4）按照文件类型、修改类型、变更类型对数据进行标记；

（5）对文件的MIME类型、编码、字符集等进行识别与优化处理；

（6）异常数据处理。如不同目录下的同名文件，系统会默认为是同一个文件，这会导致后续对变更代码的分析混乱。处理方法是：为每个文件添加时间戳进行区分。

2.2.3 形成数据源

经原始数据获取和数据处理后，形成本次量化管理系统的数据源，数据库结构设计可见表2。

2.3 变更数据量化管理

以获取到的变更数据为数据源，使用JavaEE相关技术，开发变更数据量化管理系统。

2.3.1 数据更新

数据更新模块提供版本库信息展示与更新功能。对此可展开研究分述如下：

（1）设置版本库。设置要进行量化管理的SVN版本库地址，支持http、https、svn、file协议；

（2）数据更新。设置对版本库的数据更新方式，可选手动更新或自动定时更新。用于实时跟踪开发进度；

（3）信息展示。默认展示版本库中最新信息，包括版本库地址、最新版本号、最新提交日期和提交者。进行数据更新时，实时显示系统状态。

2.3.2 代码统计

设置拟研究的开发者和时间段进行统计。首先指定开发者，可选全部或单一开发者；然后指定时间，可选某天、某月、某年或任意时间段。研究可得，该项技术主题的分析阐释可见如下。

（1）代码修改量。对指定的开发者在指定时间段内，针对代码的增加和删除行数进行统计，方便用于一些指标，诸如活跃度、开发效率的分析。为此，可给出某成员的统计运行效果如图2所示；

（2）影响文件类型。对指定的开发者在指定时间段内，提交的所有版本影响的文件类型进行统计，区分代码文件、配置文件或非文本文件；

（3）修改文件个数。对指定的开发者在指定时间段内，提交的所有版本影响到的文件进行统计；

（4）变更类型分析。对指定的开发者在指定时间段内，发生的代码修改进行归类分析。可分为修改方法体、增加方法、代码重构、修复bug等。

2.3.3 量化指标

（1）团队

① 团队效率。该团队在指定时间段内，对代码的增、删行数的平均值；

② 团队活跃度。该团队在指定时间段内的活跃情况；

③ 团队成员贡献量。团队所有成员在指定时间段内的工作量查看和比较，呈现效果如图3所示。

（2）成员

① 开发效率。该成员在指定的时间段内，对代码的修改量，以及与团队平均水平的比较；

② 修改文件类型。该成员在指定的时间段内，所有对软件项目的修改所影响到的文件类型；

③ 活跃度。显示该成员在指定时间段内的活跃时间与活跃度；

④ Bug修复量。指定时间段内修复的Bug数量，以及修改指定Bug所耗时间；

⑤ 产出量。指定时间段内的代码产出量和功能產出量，可以查看月产出、季度产出等。

2.3.4 内容查看

对指定文件的任意版本内容进行查看，并可以比较任意版本之间的变更内容。研究重点可概述如下。

（1）文件内容查看。指定文件名（文件路径）、版本号，展示文件的增加时间、修改时间、文件类型及文件内容；

（2）变更内容查看。指定文件名、变更前后的版本号，展示该文件在这2个指定版本间的变更内容。

3 结束语

本软件开发过程量化系统，通过获取软件开发过程中的变更数据并协同数据处理，实现了对软件开发过程的量化管理。后续根据量化结果，可以对工作量、缺陷数、熟练度、开发能力等具体数据进行度量，确定开发者的开发能力等级，进而获得对人员、团队、公司的生产率的度量、项目进度管理和进度预警；并可以结合COCOMOⅡ模型，形成适用于该机构的工作量估算模型和软件成本估算模型。

参考文献

[1] 侯成功，谭裴，叶敏. IFPUG功能点分析方法在电信行业软件中的应用[J]. 软件导刊，2017，16（9）：142-144，147.

[2] 张旭，刘浩驰. 基于CMMI的量化管理在项目中的应用与研究[J]. 电脑与电信，2016（4）：62-65.

[3] 罗娟，陆东晖，徐霞. 基于CMMI4的软件项目量化质量管理研究[J]. 软件导刊，2016，15（6）：8-10.

[4] 杨培培，赵海生，张金栋. Wideband_Delphi技术在软件估算中的应用[J]. 电子质量，2017（10）：39-42.

[5] BOEHM B W CLARK HOROWITZ et al. Software cost estimation with Cocomo II with Cdrom[M]. Upper Saddle River NJ USA： Prentice Hall PTR 2000.

[6] 魏来，刘海涛，付祎. 基于偏最小二乘回归的COCOMO模型校准方法[J]. 统计与决策，2016（8）：73-76.

[7] 李亚红，郝克刚，葛玮. 基于GQM模型的软件项目进度的度量过程[J]. 计算机应用，2005，25（6）：1448-1450.

[8] 戴炳荣，王凌，李超，等. 一种在GQM度量方法中的决策机制研究[J]. 计算机应用与软件，2017，34（5）：19-23.

[9] 姜文，刘立康. 基于持续集成的软件度量[J]. 计算机测量与控制，2017，25（5）：136-139.