CN109062783A - 一种面向TopCoder的群体软件质量的评价系统与方法 - Google Patents

Abstract

本发明涉及一种面向TopCoder的群体软件质量的评价系统与方法，以传统软件质量工程研究为导向，进行面向TopCoder平台的群体软件质量研究。从三个角度描述群体软件质量：项目评分以百分制的形式，作为项目质量的直接反映；项目工作量，通过项目开发过程中的开发者工作工时，同时质量保证工作量，为项目发布后用以维护和修改项目所需的开发者工作工时，二者从作为侧面描述质量的度量，是质量工程的基础研究。通过针对三方面构造合适的模型和优化方法，指导平台管理者，协作具体项目管理者，利用和整合松散自由的开发者社区的信息，以大数据理念指导项目管理者的工作方向。

Description

一种面向TopCoder的群体软件质量的评价系统与方法

技术领域

本发明涉及一种面向TopCoder的群体软件质量的评价系统与方法，属于计算机软件与理论技术领域。

背景技术

群体软件开发模式，是创新性的应用众包开发方法于软件工程领域，新型的问题解决模式，是一个极具前景的研究领域。群体软件开发表现为：许多软件从业者通过互联网等开放平台，使用自己的经验和技术参与软件开发相关的任务。已知有效的群体软件开发实践是在众包平台(如TopCoder)上开发的竞争性群体软件项目。群体软件开发方法的低成本、短时间、高效率特点，使其在面临当今软件系统越来越复杂的新形势中，显示出巨大的潜力。

根据开发模式的不同，支持群体软件应用的开发平台主要有两大类。第一种是基于竞争的群体软件开发模式，比如TopCoder，它以在线编程竞赛的形式运行软件开发任务，是一个比较成熟的群体软件开发实践平台，如今注册开发者(网站显示为Active members)已超过100万人次，它以竞赛的形式向社区发布软件开发任务，以奖金作为奖励机制，吸引社区开发者参与，最终从提交的作品中选取最佳解决方案。另一种是基于协作的群体软件开发模式，例如Github，项目托管和开发者社交网站。从软件开发生命周期(SDLC)涉及的开发活动的覆盖范围来看，群体软件开发可分为面向过程和面向特定阶段的。面向过程的平台(如TopCoder)可以支持各种开发活动，而面向阶段的软件(例如uTest)倾向于专门支持某些软件开发活动。

软件质量评价体系的研究，是传统软件工程中重要的研究方向，对于群体软件工程这个新形式也不例外。只有推进和建立群体软件工程质量评价系统化研究，才能充分发挥应有潜力，同时有助于指导软件项目管理人员高效解决开发过程中的问题。虽然群体软件工程开发方法作为解决复杂系统的解决方案，已经广泛为大家接受，但是并未出现针对此种开发方法的相应评价标准，传统软件质量评价标准，代表有ISO/IEC 9126标准。由于群体软件开发的开发人员不固定，开发周期短等特点，传统的方法并不能完全适应于群体软件开发方法。评价标准的缺失致使项目管理者，无法从客观的角度对项目质量进行评价，进而导致在软件上线发布后的后期维护成本超出预期，影响产品实用性。

发明内容

本发明的技术解决问题是：克服现有群体软件质量理论研究的缺失，关注于完整项目过程，提供一种面向TopCoder平台项目的，群体软件质量评价的体系与方法，构造合适的模型和优化方法，指导平台管理者，协作具体项目管理者，利用和整合松散自由的开发者社区的信息，以大数据理念指导项目管理者的工作方向。

本方法的应用价值在于借助项目评分与项目工作量，这两种项目过程中度量，预测项目发布后，所需质量保证的工作量，以达到协助项目管理者在项目进行过程中提升项目质量的目的。

本发明提供了一种面向TopCoder的群体软件质量的评价系统，该评价系统基于传统软件质量工程模块，还包括项目评分度量模块、项目工作量度量模块和质量保证工作量度量模块，其中：

传统软件质量工程模块：通常用软件中的缺陷数量(缺陷率)或者软件在遇到崩溃情况之前可运行时长(即：平均失效时间(MTTF))来测量软件产品质量；软件产品质量通过缺陷密度度量来反映，缺陷密度度量采用规定时间里的缺陷数量除以出错机会计算得到缺陷数量，是指导致软件失效的不同原因的个数；出错机会即软件的规模，用千行源代码数(KLOC)表示；缺陷密度度量的计量方法为千行代码错误率，千行代码缺陷率与软件产品质量成正比；

本发明提出的基于群体软件质量的评价系统，基于传统软件质量工程的研究，而不局限于此。抛弃直接使用这一指标的想法，关注应用这一指标的最终目标：预测质量保证工作的工作量，并探索如何减少它。研究质量保证工作量度是软件度量计划的目标之一，如与摩托罗拉软件度量计划的目标之一是一致的，即降低不合格部分所需的成本。

项目评分度量模块：使用项目评分反映项目质量；项目评分度量用于评估完整过程项目的完成质量，考虑流程中所有比赛对项目整体的影响。具体在进行项目评分度量时，采用模块化和过程化两种聚合方法对项目评分进行聚合，考虑流程中所有比赛对项目整体的影响，将低层次的组成完整过程项目的比赛评分(比赛评分由专家经验性判断给定)进行聚合，形成可代表项目整体质量的高层次项目评分。在一定程度上，可认为项目评分与项目质量具有强关联，这是因为项目评分是从整体角度来看待完整过程的项目，而项目评分是由低层次的比赛评分组成、聚合。这涉及到经验分析，在传统的软件质量分析中称之为定性分析方法，低层次比赛评分是由同行业的专家评审者给出的，他们从潜在的注册开发者中招募而来，在所评类型中有较高的能力值。由于低层次的比赛评分包含软件开发生命周期的各个阶段评分，所以可从不同角度反映了开发过程中的软件质量。

项目工作量度量模块：使用项目工作量更精确替代代码量；项目工作量度量用来评估一个软件项目需要多少工时或投资，以完成此项任务，评估项目工作量是软件质量评估的基本且重要的指标；具体在对项目工作量进行估计时，首先使用功能点分析法(FPA)来估计项目的规模，项目的规模的估计需要进行代码行数的估计，然后通过相应的模型将描述项目规模的代码量，转换成工时；基于构造成本模型的方法除考虑项目规模因素，还要考虑规模影响因素和成本驱动因素；由于构造成本模型的一些局限，也应用多元线性模型和决策树模型进行估计，特征选择借鉴成本构造模型应用特征，以对比估计结果优劣，进行模型选取。本模块应用基于源代码行数的工作量估计方法，这是一种从开发者的角度进行工作量估计的方法。源代码量是软件开发的初期，项目管理者估计软件规模的方法，使用工作分解结构法或模拟方法进行代码行数的估计。然后通过参数化模型将描述项目规模的代码量，转换成工时(单位：人-天)。本方法采用的参数化方法基于构造成本模型COCOMO的研究；

质量保证工作量度量模块：使用质量保证工作量反应项目发布后的缺陷数；质量保证工作量代表了维护过程中所需的工作量。在面向TopCoder的群体软件工程研究中，质量保证工作量的估计，通过寻找软件缺陷类型比赛(Bug Hunt)的相关特征进行反映。寻找软件缺陷类型比赛(Bug Hunt)一般在软件系统发布后，在运行过程中，由于项目管理者经过评定认为软件可能存在一些缺陷，发布此类比赛悬赏寻找软件潜在的缺陷。对于此度量的估计研究，借鉴部分项目工作量度量估计的研究成果，但不能应用COCOMO模型，因为此过程非软件开发过程中阶段。具体在对质量保证工作量进行估计时，应用多元线性模型和决策树模型进行估计，选取的特征包括寻找软件缺陷类型比赛的注册人数，比赛提交人数，比赛奖金数，人员技术水平，比赛说明文档平均长度，比赛平均难度。

本发明还提供了一种面向TopCoder的群体软件质量的评价方法，该评价方法基于权利要求1所述的面向TopCoder的群体软件质量的评价系统，主要包括以下步骤(1)－(5)：

步骤(1)采用模块化和过程化两种聚合方法对项目评分进行聚合，考虑流程中所有比赛对项目整体的影响，将低层次的组成完整过程项目的比赛评分(比赛评分由专家经验性判断给定)进行聚合，形成可代表项目整体质量的高层次项目评分。

步骤(2)对项目工作量进行估计，首先使用功能点分析法(FPA)来估计项目的规模，项目的规模的估计需要进行代码行数的估计，然后通过相应的模型将描述项目规模的代码量，转换成工时；基于构造成本模型的方法除考虑项目规模因素，还要考虑规模影响因素和成本驱动因素；由于构造成本模型的一些局限，也应用多元线性模型和决策树模型进行估计，特征选择借鉴成本构造模型应用特征，以对比估计结果优劣，进行模型选取。此步骤，基于传统工作量估计方法，融合多种方案，并创新性应用多元线性及决策树估计工作量，体现在：(21)基于源代码行数的工作量估计方法，测量项目的规模需要正确的收集到整个项目的所有源代码，需要包括各个组件的头文件，配置文件等。本方法应用功能点分析法(FPA)来估计项目的规模，同时创新性应用线性回归方法进行项目规模模型构建；(22)将基于源代码行数的工作量估计方法进行拓展，应用参数化模型将项目规模转化为工时。应用的参数化软件工作量模型，以成本构造模型第二版COCOMOII为基础进行拓展研究，主要研究多元线性模型、回归决策树模型和随机森林模型等有别于传统软件工作量估计方法的技术，应用于工作量估计的可行性与准确度。

步骤(3)对质量保证工作量进行估计，应用多元线性模型和决策树模型进行估计，选取的特征包括寻找软件缺陷类型比赛的注册人数，比赛提交人数，比赛奖金数，人员技术水平，比赛说明文档平均长度，比赛平均难度。

步骤(4)分析项目评分，质量保证工作量、项目工作量三者比例关系，并选择最佳分数聚合方法；在用于训练的、完整的项目中，项目工作量和质量保证工作量能够通过真实衡量得到，而项目评分需要通过聚合决策而得，在确认项目评分，质量保证工作量、项目工作量三者关系后，通过对项目评分a、项目工作量和质量保证工作量的比值b进行皮尔逊相关性分析与显著性分析，可确定最佳聚合方法用于项目评分的聚合决策；同时通过显著性分析的结果，还可确定a与b对应的线性关系。此步骤，基于传统软件质量工程研究，创新性拓展传统质量度量指标，以适应面向TopCoder的群体软件工程项目，体现在：(41)提出从传统软件工程质量研究的度量，千行代码错误率出发，结合群体软件工程实际，对传统错误率度量组成部分进行分析与重定义，形成完整的面向TopCoder平台项目的群体软件质量评价体系；(42)对度量组成部分进行皮尔逊相关性分析与显著性分析，间接推断无具体数据支持的评分聚合过程中，最佳的聚合方案。

步骤(5)在应用场景中，已知项目工作量和项目中所有比赛的得分，通过聚合得到项目评分，继而通过步骤(4)中确定的线性关系，估计质量保证工作量。

进一步的，上述群体软件质量的评价方法中，所述步骤(1)中采用模块化和过程化两种聚合方法对项目评分进行聚合具体为：

所述模块化聚合方法以Squale模型为代表，Squale模型同等的对待软件开发过程中所有的开发阶段，而且能满足强调需要被更改的不良结果部分的需求；

所述过程化聚合方法需要构建一个基于聚类分析和线性回归分析的面向过程化的聚合模型：首先，按照不同开发阶段获胜分数均分，将完整项目进行分组；然后根据聚类的结果，进一步计算每一开发阶段对整体的权重，生成评价面向TopCoder的群体软件项目整体质量的线性模型。由于以Squale模型为代表的模块化方法无法描述聚合部分之间的差异，因此不局限于模块聚合方法，考虑到软件开发生命周期中，不同类型比赛对项目整体质量影响不同，提出面向过程的聚合方法，进行完整开发过程的项目的评分聚合。在采用过程化聚合方法时，创新性构建了一个基于聚类分析和线性回归分析的面向过程化的聚合模型。基本思想是，按照不同开发阶段获胜分数均分，将完整项目进行分组。根据聚类的结果，进一步计算每一开发阶段对整体的权重，生成评价TopCoder项目质量的线性模型。

本发明与现有技术相比的优点在于：

(1)创新性提出从传统软件工程质量研究的度量，千行代码错误率出发，结合群体软件工程实际，形成完整的面向TopCoder平台项目的群体软件质量评价体系；

(2)对软件质量的聚合研究，不局限于模块化方法，考虑到软件开发生命周期中，不同类型比赛对项目整体质量影响不同，创新的提出应用过程化的方法进行聚合，通过计算不同类型比赛的权重，综合评判项目整体质量。模块化方法与过程化方法应用对评价体系影响比较，其中在显著性方面，小于0.05认定为显著。在相关性方面一般相关性绝对值大于0.6-0.8认为有强关联，大于0.8认为有极强关联。

表1模块化方法与过程化方法应用对评价体系影响比较

方法	皮尔逊相关性	显著性(双尾)
			模块化-平均法	-0.608	0.148
模块化-Squale	-0.642	0.12
			过程化-基于聚类	-0.83	0.021
过程化-基于奖金	-0.767	0.044

(3)项目工作量估计理论不局限于传统的构造成本模型COCOMO，而是探索更为普适化、在各种领域的估计研究中都广为应用的多元线性模型和决策树模型。在对比实验中，给出四种方法的对比结果，其中基准方法为随机猜测方法，基于决策树的方法有决策回归树模型和随机森林模型，实验证明多元线性模型和决策树模型更能结合群体软件这一新型软件开发模式的实际，估计准确度更高。

(4)体系应用目的性更强，以往的质量评价体系目的在于构建模型，形成度量以评价项目质量。而本方法所构建体系，目的在于降低不合格部分所需的成本，以指导项目管理者通过合理方法规划项目，提升项目评分，优化项目工作量，从而降低质量保证工作量。

附图说明

图1为本发明的组成框图；

图2为图1中项目评分进行聚合的实现流程图；

图3为图1中项目工作量的估计流程图；

图4为项目工作量估计方法对比图；

图5为图1中参赛选手能力评价模块流程图。

具体实施方式

如图1所示，本发明拓展自千行代码错误率，包括项目评分，项目工作量和质量保证工作量三个角度的度量。

其中软件任务作为目标，被分解成比赛这一的基本单位。而软件的项目质量作为反应软件完成好坏的指标，本模型应用项目评分直观进行反映，项目评分是由基本单位的比赛评分进行聚合的结果。

为了客观评价聚合策略的优劣，传统软件质量需要通过软件缺陷数与代码量的比值进行反应，而应对面向TopCoder的群体软件质量评价实际，本模型通过质量保证工作量和项目工作量的比值进行反映。项目工作量的估计通过项目规模估计拓展进行估计运算，质量保证工作量的估计通过寻找软件缺陷类型比赛的相关特征进行反映。此外质量保证工作量的估计也作为指导项目管理者优化项目的重要指标。

如图2所示，本发明中项目评分的聚合步骤如下：

模块化方法应用Squale模型为代表进行TopCoder项目质量评分聚合的过程。受到Squale模型启发，将项目评分定义成低等级评分和高等级评分，在实践中，操作步骤如下：

(1)计算过程中各阶段的比赛平均分，并将分数转化到[0,3]范围内，每一个阶段的分数称之为一个独立评分IM；

(2)然后在权重函数4.4中应用IM进行计算，其中权重参数λ，本方法将其定义为项目的难度平均值。比赛的难度定义，是一种应用特征聚类方法将不同类别比赛进行区分的测量指标。所依据的特征包括奖金数量，项目周期等，一定程度上反应了参赛者为达到比赛需求所付出的努力程度；

g(IM)＝λ^-IM (1)

(3)之后，将计算权重后的分数取平均值

(4)最后，应用反函数将以上分数返回到[0,3]范围内，反函数为g^-1(IM)＝-log_λ(IM)。完整的计算一个完整过程项目高级别评分的计算过程如下：

由公式2可见，当λ的值较大时，项目的高级别评分会收敛到低级别评分的低分数区；当λ的值较小时，高级别评分会十分接近平均值。在应用过程中，λ的取值为难度值的倒数，当项目平均难度较低时，项目管理者对完成度的期望相对较高，所以期望比赛都有较高的分数，这种情况下出现较低分数的组成部分，会对整体的影响很大，造成最终完整过程项目的评分与期望评分有较大差距。相反的，当项目平均难度较大时，项目管理者对项目的期望较低，所以期望得分较低，对低评分容忍度较大，偶尔的有评分较低的比赛，不会造成结果与期望的较大差距。

过程化方法应用构基于聚类分析和线性回归分析的面向过程化的聚合模型。基本思想是，按照不同开发阶段获胜分数均分，将完整项目进行分组。根据聚类的结果，进一步计算每一开发阶段对整体的权重，生成评价TopCoder项目质量的线性模型。

(1)利用TopCoder完整项目的九个阶段平均分数作为聚类的主要特征。这些特征包括：概念化设计(C1)、软件需求(S2)、软件架构(AR3)、界面原型设计(UI4)、组件设计(DS5)、场景测试(TSC6)、组件开发(DV7)、组件集成(AS8)、套件测试(TSU9)。聚类的结果将，具有相似的阶段评分分布的完整项目，划分到同一组中，将完整过程项目分割成X组。

(2)根据聚类结果为每个阶段分配计算质量评分的加权系数，权重的计算方法如表2。其中比赛评分矩阵：一条记录为包含9个阶段分数的向量，共62条记录。

聚类中心分数矩阵形式如下：

在算法中，应用奖金投入总量，作为权重计算的一部分，并进行标准化。算法的核心部分是计算每一个项目的分数与聚类中心的距离，由于算法基于K-means，因此此处的距离计算方法应用欧氏距离。

表2基于聚类的阶段i权重计算

如图3所示，本发明中群体软件项目工作量估计具体实现如下：

(1)应用功能点分析法(FPA)来估计项目的规模。功能点估计法由国际功能点用户组织构建并维护支持(IFPUG,ISO/IEC 20926[52])，它可以在软件开发的生命周期早期应用，以估计软件的代码规模，而不依赖于真实的代码量。照功能点计数实践手册(版本4.2.1)的定义，应用功能点估计法遵循如下步骤：

A)按照功能点类型，对软件系统的规模进行功能点计数，功能点类型分为，外部输入(EI)，外部输出(EO)，内部逻辑文件(ILF)，外部接口文件(EIF)，外部查询(EQ)。

B)确定每个功能点的复杂程度。将每个功能点分为低，中和高三个复杂度级别。判断标准包含：所有类型的数据元素数量(DET)，以及ILF和EIF的记录元素数量(RET)，EO，EQ和EI的文件类型数量(FTR)。

C)为每种功能点，计算未调整功能点数(UFP)。

D)将UFP转化成代码行数，在项目规范文件中可以找到项目管理者对项目的编程语言要求。

(2)应用参数化模型将项目规模转化为工时。工时是考量一个软件项目最合理的度量，输出结果为人-天或人-小时的模型可以满足此需求，本方法应用的参数化软件工作量模型。以成本建模模型第二版(COCOMO II)为代表。根据公式6可见，项目的规模可通过对其施加影响因素的方式，转化到软件项目工作量，针对COCOMO II的研究是项目工作量研究的基础。公式7中的E值，为5个与项目的开发过程相关的规模影响因子(先验性，开发灵活性，体系结构/风险化解，团队凝聚力，过程成熟度)的聚合，定义在软件规划阶段，EM值为17个软件系统相关的成本驱动因子(包含产品因素，平台因素，项目因素和人员因素四个方面的内容)，定义在软件完成后的分析阶段，因此COCOMO II又称后体系成本建模。

(3)应用多元线性模型和决策树模型进行估计方法对比研究。应用多元线性模型构建项目工作量估计的模型，潜在的特征包括来自COCOMO II的5个规模特征和17个成本驱动因子，也包括项目规模(size)，项目种比赛总数(numContest)，项目开发过程经历的阶段数(numPhase)。通过在训练过程中对每个特征进行皮尔逊相关性分析。得到结果如表3：

表3项目工作量系数计算及分析

根据结果发现，项目工作量与项目规模，项目包含的比赛数量，语言和工具经验(成本驱动因子中的LTEX)密切相关，因此构建如下的多元线性模型：

项目工作量＝32.99+4.71×size+6.25×numCon+1.07×ltex (8)

本发明项目工作量估计理论不局限于传统的构造成本模型COCOMO，而是探索更为普适化、在各种领域的估计研究中都广为应用的多元线性模型和决策树模型。如图4所示，在对比实验中，给出四种方法的对比结果，其中基准方法为随机猜测方法，基于决策树的方法有决策回归树模型和随机森林模型，实验证明多元线性模型和决策树模型更能结合群体软件这一新型软件开发模式的实际，估计准确度更高。

如图5所示，本发明中质量保证工作量估计具体实现如下：

对质量保证工作量的特征建模工作，选取的特征包括Bug Hunt比赛注册人数(Register)，比赛提交人数(Submitter)，比赛奖金数(invest)，人员技术水平(Tech)，比赛说明文档平均长度(Doc)，比赛平均难度(avgDiff)等。多元线性模型构建以及进行显著性分析的结果见表4。

表4质量保证工作量系数

可见质量保证工作量与奖金投入和比赛平均难度最为相关，因此构建如公式9的质量保证工作量估计模型。

质量保证工作量＝-72.28+4.101×register+12.09×tech (9)

总之，利用群体软件开发方法解决大规模复杂系统所带来的软件危机，本发明提出完整的群体软件质量评估体系与方法，从传统质量评估理论出发，创新性应用项目工作量与质量保证工作量的理论进行项目质量的评价，并提出可行性高的可反映项目质量的项目评分聚合方法，最终回到此体系的目标，在项目完成未发布前，根据项目评分与项目工作量，计算质量保证工作量，给予项目管理者决策以参考依据，以提高群体软件项目整体质量。

Claims (3)

1.一种面向TopCoder的群体软件质量的评价系统，其特征在于：该评价系统基于传统软件质量工程模块，还包括项目评分度量模块、项目工作量度量模块和质量保证工作量度量模块，其中：

传统软件质量工程模块：通常用软件中的缺陷数量或者软件在遇到崩溃情况之前可运行时长来测量软件产品质量；软件产品质量通过缺陷密度度量来反映，缺陷密度度量采用规定时间里的缺陷数量除以出错机会计算得到缺陷数量，是指导致软件失效的不同原因的个数；出错机会即软件的规模，用千行源代码数表示；缺陷密度度量的计量方法为千行代码错误率，千行代码缺陷率与软件产品质量成正比；

项目评分度量模块：使用项目评分反映项目质量；项目评分度量用于评估完整过程项目的完成质量，考虑流程中所有比赛对项目整体的影响；具体在进行项目评分度量时，采用模块化和过程化两种聚合方法对项目评分进行聚合，考虑流程中所有比赛对项目整体的影响，将低层次的组成完整过程项目的比赛评分进行聚合，形成可代表项目整体质量的高层次项目评分；

项目工作量度量模块：使用项目工作量来精确替代代码量；项目工作量度量用来评估一个软件项目需要多少工时或投资，以完成此项任务，评估项目工作量是软件质量评估的基本且重要的指标；具体在对项目工作量进行估计时，首先使用功能点分析法(FPA)来估计项目的规模，项目的规模的估计需要进行代码行数的估计，然后通过相应的模型将描述项目规模的代码量，转换成工时；基于构造成本模型的方法除考虑项目规模因素，还要考虑规模影响因素和成本驱动因素；由于构造成本模型的一些局限，也应用多元线性模型和决策树模型进行估计，特征选择借鉴成本构造模型应用特征，以对比估计结果优劣，进行模型选取；

质量保证工作量度量模块：使用质量保证工作量反应项目发布后的缺陷数；质量保证工作量代表了维护过程中所需的工作量；在面向TopCoder的群体软件工程研究中，质量保证工作量的估计，通过寻找软件缺陷类型比赛的相关特征进行反映；所述寻找软件缺陷类型比赛一般在软件系统发布后，在运行过程中，由于项目管理者经过评定认为软件可能存在一些缺陷，发布此类比赛悬赏寻找软件潜在的缺陷；具体在对质量保证工作量进行估计时，应用多元线性模型和决策树模型进行估计，选取的特征包括寻找软件缺陷类型比赛的注册人数，比赛提交人数，比赛奖金数，人员技术水平，比赛说明文档平均长度，比赛平均难度。

2.一种面向TopCoder的群体软件质量的评价方法，其特征在于：该方法基于权利要求1所述的面向TopCoder的群体软件质量的评价系统，主要包括以下步骤：

步骤(1)采用模块化和过程化两种聚合方法对项目评分进行聚合，考虑流程中所有比赛对项目整体的影响，将低层次的组成完整过程项目的比赛评分进行聚合，形成可代表项目整体质量的高层次项目评分；

步骤(2)对项目工作量进行估计，首先使用功能点分析法(FPA)来估计项目的规模，项目的规模的估计需要进行代码行数的估计，然后通过相应的模型将描述项目规模的代码量，转换成工时；基于构造成本模型的方法除考虑项目规模因素，还要考虑规模影响因素和成本驱动因素；由于构造成本模型的一些局限，也应用多元线性模型和决策树模型进行估计，特征选择借鉴成本构造模型应用特征，以对比估计结果优劣，进行模型选取；

步骤(3)对质量保证工作量进行估计，应用多元线性模型和决策树模型进行估计，选取的特征包括寻找软件缺陷类型比赛的注册人数，比赛提交人数，比赛奖金数，人员技术水平，比赛说明文档平均长度，比赛平均难度；

步骤(4)分析项目评分，质量保证工作量、项目工作量三者比例关系，并选择最佳分数聚合方法；在用于训练的、完整的项目中，项目工作量和质量保证工作量能够通过真实衡量得到，而项目评分需要通过聚合决策而得，在确认项目评分，质量保证工作量、项目工作量三者关系后，通过对项目评分a、项目工作量和质量保证工作量的比值b进行皮尔逊相关性分析与显著性分析，可确定最佳聚合方法用于项目评分的聚合决策；同时通过显著性分析的结果，还可确定a与b对应的线性关系；

步骤(5)在应用场景中，已知项目工作量和项目中所有比赛的得分，通过聚合得到项目评分，继而通过步骤(4)中确定的线性关系，估计质量保证工作量。

3.根据权利要求2所述的面向TopCoder的群体软件质量的评价方法，其特征在于：所述步骤(1)中采用模块化和过程化两种聚合方法对项目评分进行聚合具体为：

所述模块化聚合方法以Squale模型为代表，Squale模型同等的对待软件开发过程中所有的开发阶段，而且能满足强调需要被更改的不良结果部分的需求；

所述过程化聚合方法需要构建一个基于聚类分析和线性回归分析的面向过程化的聚合模型：首先，按照不同开发阶段获胜分数均分，将完整项目进行分组；然后根据聚类的结果，进一步计算每一开发阶段对整体的权重，生成评价面向TopCoder的群体软件项目整体质量的线性模型。