首页> 中国专利> 自动挖掘软件过程任务仓库中的高性能任务的方法和系统

自动挖掘软件过程任务仓库中的高性能任务的方法和系统

摘要

本发明公开了一种自动挖掘软件过程任务仓库中的高性能任务的方法和系统,其方法为从软件过程任务报告提取评价指标和数据,建立任务集,然后采用数据包络分析模型对任务集进行相对性能评分得到高性能开发任务集合,并为每个相对性能评分较低的任务建立最佳参考任务及其参考权重,给出量化的过程改进空间建议;其系统为三层架构模式,主要包括访问界面层、任务数据分析层、软件过程数据库三层结构;本发明提供了对软件过程的不同层次的任务数据的全面的综合评价,能有效适应软件过程任务相对性能评价中的多变元和可变规模收益等特性,自动和图表化的任务评价结果显示和分析功能,为软件过程管理人员提供了可视化的量化决策辅助支持。

著录项

  • 公开/公告号CN101110034A

    专利类型发明专利

  • 公开/公告日2008-01-23

    原文格式PDF

  • 申请/专利权人 中国科学院软件研究所;

    申请/专利号CN200710142990.2

  • 发明设计人 王青;阮利;王永吉;李明树;

    申请日2007-08-14

  • 分类号G06F9/44(20060101);

  • 代理机构北京君尚知识产权代理事务所;

  • 代理人余长江

  • 地址 100080 北京市海淀区中关村南四街4号

  • 入库时间 2023-12-17 19:41:21

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2019-08-02

    未缴年费专利权终止 IPC(主分类):G06F9/44 授权公告日:20090722 终止日期:20180814 申请日:20070814

    专利权的终止

  • 2009-07-22

    授权

    授权

  • 2008-03-12

    实质审查的生效

    实质审查的生效

  • 2008-01-23

    公开

    公开

说明书

技术领域

本发明涉及一种对存储在软件过程管理系统中的历史软件开发任务的性能数据的处理方法和系统,特别涉及一种基于数据包络分析的从软件过程管理系统的软件过程任务仓库中自动挖掘高性能任务的方法和系统,属于计算机软件工程领域。

背景技术

随着科学技术的日益发展,软件产品已经被广泛地应用在人类社会的各个方面,如银行,保险,建筑工程,贸易,通讯,娱乐,教育,交通运输等等。人们的日常生活越来越多的依赖于各种含有软件的电子设备。然而,随着计算机技术的发展,应用软件变得越来越复杂,更加难以开发和维护。软件产品存在缺陷几乎成为不可避免的事实,而这些缺陷又往往对人们的生活甚至生命安全造成严重的危害。因而,越来越多的研究人员和工程人员投身到如何提高软件产品质量的研究和实践之中,量化软件过程管理和改进近年来得到研究和工业界增强的关注,并日渐成为科学化和精确化地进行现代软件过程管理的主要手段。

软件过程通常被定义为“设计、开发、应用和维护软件产品的一组相互关联的活动、方针、组织结构、技术方法、规程以及工作产品。它定义了对软件开发进行组织、管理、度量、支持和改进的途径”。软件过程的一个重要特点是任务驱动特性,即软件过程执行过程中,人员的行为是由所承担的任务驱动的;软件过程实施的效果最终是通过过程微观层面各个环节和各个层次的任务执行情况来体现的。任务是软件过程高效执行和资源合理配置的一个关键要素。随着CMM,TSP,PSP等研究成果的日益发展,现代软件过程管理研究的重点和目标在于实现全面的和量化的软件过程管理。从组织层次来看,定量化、规模化、过程化和可控制的软件过程生产的一个首要前提是要实现对各个层次的软件过程任务的准确度量和评价,进而使管理者能够洞察产品开发全过程,把握项目的进度、开销、产品质量状态等,使整个项目的开发过程处于受控状态,为管理者制定决策提供可量化的依据。从小组层次来看,软件过程任务的评价是软件过程管理人员对小组开发人员进行绩效评价,进而实现小组人力资源有效调度和配置的一个核心基础;从个体软件过程改进层次来看,软件过程任务评价更是软件开发人员分析个体行为,识别个人软件过程改进机会的一个重要途径。量化软件过程管理技术的一个重要软件支撑平台是软件过程管理系统(尤其是以过程为中心的软件工程环境”(Process-Centered Software Process Engineering Environment,PSEE))。该系统是为实施软件开发活动提供自动化支持的软件系统,是软件组织执行软件过程管理活动的核心工具。现有的研究人员开发了大量的软件过程管理系统,例如:非商业化的原型系统如Adele-Tempo,ALF,Arcadia,CSPL,E3,EPOS,MARVEL,MERLIN,OIKOS,Oz,PEACE,PADM,SPADE,SOCCA等等,也有一些商业化的软件过程管理系统,如:IPSE 2.5,ProcessWise,Syner Vision,Process Weaver,以及中科院软件研究所的软件过程管理系统SoftPM等。软件过程任务是软件过程的原子体,现有的大多数支撑系统都以任务为主要的核心并对软件过程任务的执行情况进行了详细的存储,跟踪和分析。总之,如何分析软件过程管理系统中的任务数据,尤其是如何对任务进行相对性能评价,进而从软件过程管理系统的任务仓库中自动提取相对性能较高的任务是量化软件过程管理技术的一个关键研究课题。

然而现有的软件过程管理系统目前仍然主要关注于组织和小组层次的过程建立和分析,而缺乏对更细粒度层次的对系统中积累的历史任务数据库信息的挖掘,更缺乏对这些历史任务进行相对性能量化评价(尤其是自动化的评价和提取)的方法和系统的全面支持。此外,软件固有的知识特性使得对软件过程管理系统中的任务性能的评价(尤其是自动化的评价)面临诸多困难。最典型的问题表现在:(1)软件过程任务的评价指标难以提取。进行量化软件过程任务评价的前提是需要建立一套软件过程任务性能的评价指标体系。然而目前并不存在通用的软件过程任务评价指标体系,并且不同的组织,不同的小组,不同的个人对软件过程任务提出了不同的评价指标体系需求。这使得如何提取(特别是自动提取)软件过程任务的评价指标面临困难。(2)软件过程任务的执行性能的相对性。由于传统的工业过程中的过程执行主体为机器,机器的执行性能可由出厂时的参数决定,在生产过程中相对是固定的。该生产设备在执行生产任务时的相对性能也是相对固定的,在一定条件下能得到理论最优性能,从而工业过程的任务性能评价通常可采用和理论最优性能进行绝对评价的方法。而软件过程中各个环节的生产者是具有知识特性的生产者(如程序员),不同的生产者的执行性能随时间和空间的不同而动态变换,其执行任务的性能相对而言也具有动态性和易变性,难以得到理论最优性能。从而,软件开发任务性能的评价更适合或者可认为具有应进行相对性能评价的特性。(3)进行软件过程任务评价的输入输出指标的权重难以确定。由于软件开发任务具有动态性和多变性,不同的过程实施人员,其开发任务的评价权重也是难以确定的;即使是同一个过程实施人员,其历史任务指标权重也是不同和可变的。从而,软件开发任务的相对性能评价需要一种能直接依据数据自身特性动态调整权重的方法支持。(4)软件过程任务评价结果应蕴含量化,直观,可操作和多纬度的改进建议信息。软件过程量化管理的目标是支持软件过程管理人员进行有效软件过程改进,从而要求所提供的方法除了给出简单的评价结果外,需要给出量化和细致的过程改进方向和改进差距等建议。(5)多变元综合评价特性。软件开发任务评价时需要同时考虑质量,成本和进度等指标,而代码行,工作量和缺陷数等都是需要同时考虑和最常用的软件开发任务评价指标。如何在评价中同时考虑这些多维变元,是一个多变元综合评价问题。(6)软件开发任务评价具有可变规模收益特性。软件开发中工作产品规模和工作量,产品规模和缺陷数都呈现可变规模收益(非线性)特性。如何在评价中考虑此可变规模收益特性也是进行软件过程任务评价时需要解决的关键问题。

传统的软件开发任务评价试图利用针对工业过程设备任务的系统评价方法,通常采用与将性能与理论最优性能和均值进行比较的方法,但这些方法的指标体系建立或者简单采用标准(CMM/TSP/PSP)中的度量而没有结合组织软件过程的具体情况,没有充分考虑软件过程的中任务理论最优性能值难以得到的特性;一些研究采用基于挣值的性能评价方法,该方法提供了一种将实际性能和项目/任务目标进行对比的系统方法,但是该方法并没有考虑到跨任务评价时的任务的独特性;其它统计方法提供了将任务性能和某个理论最优性能(如理论的性能基线)进行对比的方法。然而研究报告表明在软件过程领域,更为实际和有效的做法是将任务性能和最佳实践,而不是以某个极可能难以得到的理论最优性能作为参照。多元线性回归的性能评价方法对识别最佳性能任务也具有一定的不适应性,因为它的对比参照是任务集的性能均值,而不是和相对最佳任务进行对比。此外,软件开发任务数据还具有异方差特性,现有的任务评价方法进行任务性能评价时,通常采用固定规模收益的数据包络模型,从而可能导致由于忽略了任务的可变规模收益特性而将最大的任务错误当成最有效的任务。

数据包络分析(Data Envelopment Analysis,简称DEA)是著名运筹学家A.Chames和W.W.Cooper等学者在“相对效率评价”概念基础上发展起来的一种新的评价技术。DEA方法的适用对象是一组同类型的决策单元(Decision Making Units简称DMU)。所谓DMU,是指代表或表现出一定的经济意义,将一定“输入”转化为一定“输出”的实体。在软件过程任务评价背景下,就是指软件过程任务。DEA方法的最主要应用就是根据输入/输出数据对同类型的DMU进行相对有效性的评价。DEA可视为一种新的“统计”方法,它与传统方法(如回归分析法)的区别在于:(1)传统方法是从大量样本数据中分析出样本集合整体的一般规律或趋势,但它把有效和非有效的样本混在一起进行分析,得出的生产函数实质上是一种“平均生产函数”,是“非有效”的;而DEA对有效生产前沿面的估计则是利用数学规划手段,从大量样本数据中分析样本集合中处于相对有效的样本个体,其本质是最优性,这就克服了错用生产函数的风险及平均性的缺陷,能有效适应对软件过程任务评价得相对效率评价特性;(2)DEA以决策单元的输入输出权重为变量,避免了确定各指标在优先意义下的权重;(3)对决策单元进行评价不需要知道决策单元的输入和输出之间是否存在某种显式关系;(4)评价结果与指标的量纲无关;(5)不仅给出DMU的评价结果,而且给出非DEA有效和弱DEA有效DMU的原因和改进路径,等等。总体看来,数据包络方法不需预估权重、不需事先设定输入输出间的显式函数关系、与指标的单位无关、评价结果丰富等诸多优点使其成为软件过程任务相对有效性评价的一个新的工具。

发明内容

本发明的目的是针对上述问题,充分利用数据包络分析技术在软件过程任务评价中的优势,提供一种自动挖掘软件过程任务仓库中的高性能任务的方法和系统,针对软件过程任务评价的具体特点实现软件过程任务的量化评价,进而自动提取高性能任务。并在提取过程中对相对性能较低的任务建立便于性能改进的参考任务集合。发明构思为:所述方法从软件过程任务报告自动提取评价指标和数据;然后采用数据包络分析模型(DEA CCR和DEA BCC模型)对软件开发任务集合进行相对性能评价。CCR来源于其模型提出者名字(Charnes,Cooper和Rhodes)的首字母缩写,BCC也来源于其模型提出者名字(Banker,Charnes和Cooper)的首字母的缩写。CCR模型的应用场景是任务的输入和输出满足线性关系。BCC模型的应用场景是任务的输入和输出满足非线性关系。数据包络分析模型的构造如表1所示。

表1数据包络分析模型

其次通过分析相对性能评分值对不同规模(相对大规模,相对中等规模和相对小规模)的软件开发任务识别出不同的高性能开发任务集合,通过分析任务间的参考关系为每个相对性能评分较低的开发任务建立最佳参考任务及其参考权重,给出具体的量化的过程改进空间建议;最后对评价结果进行敏度分析。所述的系统根据所提供的方法实现了基于数据包络分析的软件开发任务评价,从而为量化软件过程管理提供了决策支持。

为实现上述发明目的,自动挖掘软件过程任务仓库中的高性能任务系统采用下述的技术方案:

一种自动挖掘软件过程任务仓库中的高性能任务的系统,包括一软件数据库层,数据分析层,其特征在于:

所述软件数据库层为一软件过程数据库,存储软件过程任务报告数据;

所述数据分析层包括:

一任务评价指标提取器,自软件过程数据库中提取软件任务报告度量的任务报告数据;

一任务相对性能评分器,用于接收任务评价指标提取器的数据,根据数据包络分析模型进行任务报告数据的相对性能评分;

一参考任务识别器,用于接收任务评价指标提取器的数据,根据数据包络分析模型得出其他任务相对于给定任务的参考权重,识别给定任务的参考任务集合。

所述软件任务报告度量包括但不限于下列任务报告度量的一种或几种:任务工作量,或程序规模,或程序缺陷数,或文档数目。

所述数据包络分析模型选自CCR模型或BCC模型。

所述数据分析层还包括一任务评价数据预处理器,用于去除任一软件任务报告度量中任务报告数据为空的任务。

所述数据分析层还包括一评价结果敏度分析器,用于计算所有任务相对性能评分的均值,同时依次轮换去除所述高性能任务集合的一项任务,计算任务集合中的剩余任务的相对性能评分均值,根据两均值的差值判定相对性能评价是否有效,在无效时指令任务评价指标提取器重新提取数据。

所述软件过程数据库选自软件过程个体层次数据库,软件过程小组层次数据库,或软件过程组织层次数据库。

所述参考任务识别器根据程序规模对任务报告数据进行分类,在同类任务报告数据中识别给定任务的参考任务。

所述系统还包括一访问界面层,包括

一任务报告数据信息浏览界面,用于提取、显示任务报告数据;

一任务报告填写界面,用于新建任务报告数据并存储到数据库层;

一任务报告修改界面,用于修改任务报告数据并存储到数据库层;

一任务报告删除界面,用于删除数据库层的任务报告数据;

一任务相对性能评分分析界面,用于对任务报告数据进行数据包络分析,并显示分析结果;

一参考任务分析界面,用于参考任务识别,并显示识别结果;

一评价结果敏度分析界面,用于任务评价的敏度分析并显示分析结果。

一种自动挖掘软件过程任务仓库中的高性能任务的方法,其步骤包括:

1)从软件过程管理系统中提取设定的软件任务报告度量的任务报告数据创建任务集合;

2)将软件任务报告度量中的任务报告数据作为参数输入数据包络分析模型,计算该任务在该模型中的相对性能评分θ值,并创建θ≥1的任务集合作为高性能任务集合;

3)对于给定的一任务ti,根据数据包络模型计算其他任务ti,r相对该设定任务的参考权重λi,r值,并创建λi,r≠0的任务集合作为任务ti,r的参考任务集合;

4)提取参考任务集合与高性能任务集合的交集中参考权重最大的任务作为给定的任务ti的最佳参考任务。

所述软件任务报告度量包括但不限于下列任务报告度量的一种或几种:任务工作量,或程序规模,或程序缺陷数,或文档数目。

所述方法1)中丢弃任一所述软件任务报告度量中任务报告数据为空的任务。

所述数据包络分析模型选自CCR模型或BCC模型。

所述方法还包括对最佳参考任务进行敏度分析,计算所有任务相对性能评分的均值,依次轮换去除所述高性能任务集合的一项任务,计算任务集合中的剩余任务的相对性能评分均值,如两均值的差值均在设定的范围内,则认定该相对性能评分有效,否则重新从软件过程管理系统中提取任务报告数据。

所述方法可以根据程序规模对参考任务集合的任务进行分类,在与给定任务在程序规模上同类的参考任务中提取最佳参考任务。

所述方法在1)中的任务报告数据取自软件过程管理系统的个体层次数据库,小组层次数据库,或组织层次数据库。

本发明的技术效果在于:(1)在数据层,融合现代软件过程全面质量管理的理念,提供了对软件过程的不同层次(个体软件过程(PSP),小组软件过程(TSP),组织软件过程(CMM))的任务数据的全面的综合评价;(2)采用的基于数据包络分析的软件过程任务评价方法能有效适应软件过程任务相对性能评价中的多变元和可变规模收益等特性;(3)自动和图表化的任务评价结果显示和分析功能,为软件过程管理人员提供了可视化的量化决策辅助支持。

附图说明

图1.基于数据包络分析的自动挖掘软件过程任务仓库中的高性能任务系统架构示意图;

图2.基于数据包络分析的自动挖掘软件过程任务仓库中的高性能任务方法流程图。

具体实施方式

下面结合附图,以针对个体软件过程层面(如图1)的软件过程任务的评价为实例,对本发明作进一步的说明,但不构成对本发明的限制。

一种自动挖掘软件过程任务仓库中的高性能任务的系统,其采用当前流行的三层架构模式,具体实现如图1所示。其主要包括访问界面层、任务数据分析层、软件过程数据库三层结构。其中所述访问界面层主要实现了对用户的输入和向用户输出的处理;其中所述任务数据分析层主要负责处理整个系统的业务逻辑;其中所述的软件过程数据库层主要负责软件过程管理系统中软件过程任务相关的数据存储和检索。所采用的访问界面层/任务数据分析层/软件过程数据库三层结构将整个系统的表现层和业务逻辑进行合理划分,保障了系统较强的可扩展性和重用性,具体实现包括:

A.访问界面层包括任务数据维护界面区和任务数据结果分析界面区两大功能区。其中任务数据维护界面区包括:

A1:软件过程任务基本信息浏览界面,该界面主要实现了对软件过程管理系统中的任务基本信息的显示。任务报告的基本字段信息包括:任务名称,任务负责人,计划开始时间,计划完成时间,实际开始时间,实际完成时间等。

A2:软件过程任务报告填写界面,该界面主要实现了新建一个任务报告,填写任务报告的基本信息,然后保存该新建任务至软件过程管理系统中。

A3:软件过程任务报告修改界面,该界面主要实现了查询出软件过程任务报告数据库中的某个任务,修改该任务报告并保存修改的结果至软件过程管理系统中。

A4:软件过程任务报告删除界面,该界面主要实现了从软件任务报告数据库中删除某个任务。

任务数据分析结果界面区包括:

A5:软件过程任务相对性能评分分析界面,该界面主要实现了对任务报告数据采用数据包络分析模型进行自动化处理,然后将处理得到的各个任务的相对性能评分数值显示。

A6:软件过程任务参考任务分析界面,该界面主要实现了对任务报告数据采用数据包络分析模型进行自动化处理,然后将处理得到的针对整个任务集的相对性能评分为1的任务显示出来,并对相对性能评分小于1的每个任务进一步显示出DEA分析结果得到的相对性能改进权值。

A7:软件过程任务改进指标分析界面,该界面主要实现了对任务报告数据采用数据包络分析模型进行自动化处理,然后将得到的每个性能评分小于1的任务的在其每个度量指标上的指标评分值显示。

A8:软件过程任务评价结果敏度分析界面,该界面主要实现了对任务报告数据集合的采用数据包络分析得到的相对效率评分结果进行敏度分析得到的本次任务性能评分的敏度值显示。

B.数据分析层。包括任务相对性能评分器,参考任务识别器,评价结果敏度分析器,任务评价指标提取器,任务评价数据预处理器。其中任务评价指标提取器和任务评价数据预处理器为本层其它分析器提供了经预处理后的数据。

所述数据分析层的功能模块分别包含如下功能:

B1.任务相对性能评分器。该模块利用所发明的基于DEA的高性能任务集建立算法,对软件过程管理系统中的所收集的任务数据的相对性能进行评分,返回得到一个在本评价任务数据集范围内的高性能的任务集合。所发明的基于DEA的高性能任务集建立算法如下所示:

定义1任务ti={taskIDi,taskNamei,taskEvaluationMetricsi,REi}.taskIDi是任务ti的任务编号,taskNamei是任务ti的任务名称,taskEvaluationMetricsi是任务性能评价指标,REi是任务ti的相对性能评分。

定义2被评价任务集合T={t1,...,tn},其中ti是第i个开发任务。

定义3高性能任务集合:被评价任务集Г的高性能任务集HT={tj:Θ≥1,j=1,...,n}。HTIT。

定义4性能改进参考集:任务ti的性能改进参考集为RSi={tir:tir∈T,λi,r≠0,r=1,...,n}.tir是任务ti的参考任务集中的第r个任务。λir是DEA CRS/BCC模型(参见表1)的λi的系数。

定义5性能改进参考任务:任务ti的性能改进参考任务(Peer)为tir,其中tir∈RSi。ti的每个性能改进参考任务tir是相对高性能的开发任务。

定义6性能改进参考权重:任务ti的性能改进参考任务tir,对tj的性能改进参考改进权重(Peer Weight)为λir。性能改进参考权重λir表示了性能估计参考任务tir对相应的任务ti的参考价值。

定义7最佳的性能改进参考任务:任务ti的最佳性能改进参考任务为tir,其中tir是RSj中具有最大性能改进参考权重的性能改进参考任务。ti的每个性能改进参考任务tir是相对高效的开发任务。

算法具体实现如下所示:

算法1基于DEA的高性能任务集建立算法。

1.//输入:任务ti

2.//输出:任务ti的性能改进参考集RSi

3.RSi={};

4.求解DEA CCR/BCC模型优化问题,计算任务的相对性能评分REi和λir

5.Forj=1 to n do{

6.IF(λir≠0)

7.RSi=RSi ∪{tj};}

8.输出RSi

B2.参考任务识别器。任务相对性能评价的一个重要作用是提供量化过程改进差距建议,该模块利用所发明的基于DEA的任务性能改进参考集合建立算法对相对性能较低的任务计算其性能改进参考任务集合。所发明的基于DEA的任务性能改进参考集合改进算法步骤伪码实现如下所示:

算法2基于DEA的任务性能改进参考集建立算法。

1.//输入:被评价软件开发任务集T={t1,...,tn}.

2.//输出:T中相对高性能任务集HT={tj:Θ≥1,j=1,...,n}。HTIT。

3.HT={};

4.For i=1to n do{//对T中的每一个任务ti

5.求解DEA CCR/DEA BCC模型优化问题,计算任务的相对性能评分REi

6.If(REi=1)

7.HT=HT ∪{ti};}

8.输出HT。

B3评价结果敏度分析器。该模块核心实现了一个发明的敏度分析算法,以对评价结果的有效性作出分析。所发明的敏度分析算法思想为:把在前沿的任务一个个排除,然后考察其平均性能变化效果。具体实现包括调用B1分析器的“基于DEA的高性能任务集建立”算法,得到所有任务的相对效率评分值和高性能的任务集合HT,计算出所有任务的相对效率评分值的均值avg。然后依次轮换从HT中选择一个高性能任务并去除,然后计算每次对余下的任务集合中的任务的相对效率评分的均值avgi(i代表被从任务集合里面去除的任务Ti)。然后判断如果|avgi-avg|<0.1,则评价有效,否则本模块发指令给评分器指示其重新选取评价任务集。

B4任务评价指标提取器。该模块分析任务报告数据结构提取任务相对性能评价指标taskEvaluationMetrici={metri1,metri2,...,metricm},metricm∈{ProgramSize,Effort,ProgramDefects,Documents}。

B5.任务评价数据预处理器。该模块对任务评价数据进行预处理,主要对缺失数据进行处理,主要方法是该模块顺序查询任务数据库中当前提取出的任务数据集合,如果存在某个字段数值为空,则从当前所提取出的任务数据集合中删除该任务。将任务数据集合扫描一遍,直到所余下的任务数据集合中的所有任务均为不包括缺失度量数据条目的具有完整数据信息的任务。

C.软件过程数据库层。依据当前流行的的软件过程管理规范(涵盖个体/小组/组织层次)要求,该层主要包括软件过程个体层次数据库,软件过程小组层次数据库以及软件过程组织层次数据库。

其中,所述软件过程数据库层的三个部分分别存储如下的内容:

C1.软件过程个体层次数据库:存储软件过程中个体(如程序员,项目经理,质量保证人员)的执行数据(如生产率、代码行,所负责任务的缺陷等)。个体层次数据参照个人软件过程(PSP)定制的模板和表格进行收集。

C2.软件过程小组层次数据库:存储过程中各小组(如项目组,QA组等)的执行数据(如,小组的生产率,工作量等)。本小组层次数据库主要负责收集反映小组层次过程任务执行情况的数据,参照小组软件过程(TSP)进行数据收集。

C3.软件过程组织层次数据库:存储软件过程中反映组织层次任务执行性能的数据(如组织生产率,组织过程执行情况),组织层次数据库主要负责收集反映组织层次过程项目执行情况的数据,参照能力成熟度模型(CMM)中的模板进行数据收集。

一种自动挖掘软件过程任务仓库中的高性能任务的方法,其流程图如图2所示。

S1:提取软件过程任务报告数据。从互联网实验室的软件过程管理工具SoftPM(C)的个体软件过程数据库(C1)中提取任务报告属性数据。所提取的C1中的任务报告数据结构及其示例如下所示:

表2任务报告结构

 数据库字段名 实例 Task name The use logging on interface developmentin requirement management tool V 1.0 Task type Engineering PlanStartTime 2006-8-1 PlanEndTime 2006-8-7 RealStartTime 2006-8-1 RealEndTime 2006-8-9 PlanEffort 4 RealEffort 5 WorkProductSizeUnit LOC PlanWorkProductSize 100

 RealWorkProductSize 85 Task Owner Li Ruan

主要包括任务报告名称,任务类型,计划开始时间,计划结束时间,实际开始时间,实际结束时间,计划工作量,实际工作量,工作产品规模单位,计划工作产品规模,实际工作产品规模,任务负责人。本步的数据源主要由调用C1模块自动化提取。然后调用B4得到评价指标,B4在本次评价指标选取时调用的提取规则包括:

1.PlanStartTime,PlanEndTime,RealStartTime,RealEndTime,PlanEffort和RealEffort非空。

2.工作产品在任务级报告,提取其PlanWorkProductSize和RealWorkProductSize.质量平台任务类型包括Engineering,SPI(Software Process Improvement),Management,QA(Quality Assurance),Review,Test and Self-Defined。

3.只提取任务类型为工程(Engineering)的任务。

调用B4得到的任务评价指标如表3所示。

表3任务评价指标

度量类型含义单位工作量(Effort)输入任务的实际工作量人时程序规模(Size)输出任务的工作产品的程序规模LOC程序缺陷数(Defects)输出在测试阶段发现的程序缺陷数目缺陷数文档数目(Documents)输出任务中的文档数目

主要包括工作量,程序规模,程序缺陷数,文档数目。

S2:预处理软件过程任务报告数据。针对S1中提取出的任务报告数据,采用B5分析器对缺失数据进行预处理,系统处理得到的30个待评价示例任务集合如表4所示:

表4待评价任务集合

TaskSize Defects Documents Effort1.1579 12 6 7.52.1320 10 5 73.1202 8 7 7.54.1000 5 5 75.980 9 2 6.5

  6.  940  7  4  6  7.  824  6  5  6.5  8.  763  7  5  5  9.  744  5  5.5  6  10.  735  6  4  7  11.  725  5  5.5  5.5  12.  718  6  6  6  13.  700  4  3  5.4  14.  685  9  5  5  15.  678  7  6.5  5.5  16.  620  3  7.5  6.5  17.  598  5  3  6.4  18.  568  3  5  5.5  19.  460  5  3  6.5  20.  458  4  2.5  6  21.  345  5  4  5.3  22.  263  3  5  5.1  23.  236  5  3  3  24.  233  4  3  3.5  25.  220  2  4  3  26.  200  4  2.5  4  27.  178  3  1  3  28.  155  2  1.5  2  29.  144  2  1  1.5  30.  124  3  3  2

S3:任务相对性能评分。对经过S2处理的任务集(如表4),调用B1分析器自动化计算出各个任务的相对性能评分Θ。其中工作量(Effort)作为B1分析器中DEA模型的输入,程序规模(Program Size),程序缺陷数量(Program Defects),程序文档数目(Documents)作为B1分析器中DEA模型的输出。系统处理得到的任务性能评分Θ结果如表5所示。

表5任务性能评分结果

 Task Size Performance Score(Θ) CCR BCC 1.1579 1.0000 1.0000 2.1320 0.9186 0.9386 3.1202 0.9422 1.0000 4.1000 0.7953 1.0000 5.980 0.7561 0.7685 6.940 0.8217 0.8659 7.824 0.7628 0.8125 8.763 0.9593 0.9735 9.744 0.8375 0.9120 10.735 0.6140 0.6235 11.725 0.9046 0.9717 12.718 0.8727 0.9172 13.700 0.7323 0.9332 14.685 0.9182 0.9247 15.678 0.9836 1.0000 16.620 0.8946 1.0000 17.598 0.5529 0.5661 18.568 0.7788 1.0000 19.460 0.4704 0.4730 20.458 0.4918 0.5078 21.345 0.5923 0.5962 22.263 0.6826 0.7843 23.236 0.7648 0.7861 24.233 0.6637 0.6761 25.220 0.9368 1.0000 26.200 0.5128 0.5255 27.178 0.5298 0.5474

 28.155 0.8475 0.8750 29.144 1.0000 1.0000 30.124 1.0000 1.0000

系统评分结果显示,在CCR模型(参见表5和表1)中只有任务{T1,T29,T30}在性能的最前沿,而在BCC模型中{T1,T3,T4,T15,T16,T18,T25,T29,T30}在性能的最前沿。评分结果表明BCC模型(参见表5和表1)具有更好的为不同规模软件开发任务建立不同的性能基准的能力。在CCR模型中,B1分析器可将{T1,T29,T30}建立为性能基准。在BCC模型中,B1分析器得到更细粒度的性能评分{T1,T3,T4,T15,T16,T18,T25,T29,T30},进而B1可根据任务的不同规模大小建立更细粒度的性能基准。以T14为例,在BCC模型中,B1可将T15作为其改进参照,而在CCR模型中,B1只能把T1,T29或者T30作为其参照。显然,T14和T15间的规模大小差异明显的小于T14和{T1,T29,T30}。从而,在本示例中,在BCC模型下B1可建立的任务基准方案为:大规模任务性能基准为{T1,T3,T4},中等规模任务的性能基准为{T15,T16,T18},小规模任务的性能基准为{T29,T30}。

S4:识别参考任务。对在S3中得到的相对性能较低的任务(表5中性能评分EfficiencyScore<1.0000的任务),调用B2分析器自动化计算参考任务集合及其参考权重,系统处理得到参考任务集合及其评分结果如错误!未找到引用源。所示。

表6参考任务集

-ES:Effimixncy Secca;

-P:Peer;

-PW:Peer Weight

CCTLBCCOCRBOCTJESPPWESPPWTJESPPWESPPW123456789101112131.00000.91880.94220.79530.75610.82170.76230.95930.83750.61040.90460.87270.732311291301293012912930130130130129301301301201.00000.81800.19700.68570.96190.57580.26200.42770.59160.31810.55100.40240.09720.46380.73900.41600.83070.28821.05700.41230.19170.44300.37391.08550.35311.29380.37300.77121.00000.93481.00001.00000.76850.76850.81250.97350.91200.62350.97170.91720.933211429141291291342511525303416251252930341625115162514291.00000.78030.06580.15391.00001.00000.58260.41740.58260.41740.31250.08330.12190.47920.34690.19340.28250.17730.44700.10050.01670.43580.39590.31270.25010.04140.47750.04260.00710.47280.20120.24360.25240.27270.01030.63220.357514131617181920212223242526272829300.21320.23360.89460.53290.77880.47040.49180.59230.68260.76480.66370.93680.51280.52930.84751.00001.000013013013012930130129301293013013013012930130129301291293029300.35940.94790.30751.53260.23202.03420.31610.51370.12490.27131.12370.22860.30870.43980.21830.62400.18870.13501.06240.04231.88200.08410.83170.07690.06460.82460.04111.28120.06480.23150.64660.02960.91170.00820.79970.21711.00001.00000.92471.00001.00000.56611.00000.47300.30780.39820.78120.78810.67101.00000.52550.54740.57501.00001.000011330131612329181293014232911330162312930129302312930129232929300.24940.35770.39291.00001.00000.29100.14170.33731.00000.22630.33910.43430.18810.03960.13370.63860.06400.23090.70310.25570.71430.07340.11310.81140.07340.11010.81631.00000.04780.32170.63050.02370.27630.16670.08331.00001.0000

系统评分结果(错误!未找到引用源。)显示,针对本示例的参考任务集合中(表4),T7在CCR模型下的参考任务集合为{T1,T30};此外由于T30取得了最大的参考权重(0.74),系统显示T30具有更大的过程改进参考价值。在BCC模型下的参考任务集合为{T1,T3,T4,T25}。具有最大的过程改进参考权重的任务为T25。其它任务的改进参考任务和参考权重系统以此类推显示。

S5:分析评价结果的敏度。将在S1中得到的任务数据(表3),S3中得到的性能评分(表5)输入B3敏度分析器进行敏度分析。B3敏度分析器首先得到了9个前沿任务{T1,T3,T4,T15,T16,T18,T25,T29,T30}。然后B3一次排除一个任务,然后B3计算余下任务的平均性能。B3敏度分析器计算得到的30个任务的平均性能如表7所示。

表7 30个任务的平均性能

N Emean SD Emin Neff30 0.8323 0.1813 0.4730 9

其中:Emean是30个任务的平均性能值。SD为标准偏差。Emin是最小的性能评分值。Neff是高性能任务的个数。B3排除单个高性能任务后得到的平均性能值如表8所示:

表8排除单个高性能任务后的平均性能值

Task Emean 1 0.8408 3 0.8266 4 0.8303 15 0.8289 16 0.8370 18 0.8266 25 0.8327 29 0.8444 30 0.8364

其中:Task是被排除的任务。Emean是B3排除该任务后的其余任务的平均性能值。系统敏度分析显示发现没有一个前沿任务是一个极端点(即满足|avgi-avg|<0.1),也即显示本示例的评价结果是有效的。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号