CN103577882A - 一种基于uml的量化项目资源控制方法 - Google Patents

Abstract

本发明公开了一种基于UML的量化项目资源控制方法，包括确定项目管理目标与影响因子，并识别出软件过程中各阶段的子过程指标及子影响因子；根据历史项目数据识别出用于UML建模的影响因子；根据识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML模型并估算UML模型复杂度；根据识别出的子过程指标与子影响因子，建立软件过程中各阶段的过程性能基线(PPB)与模型(PPM)；根据估算的UML模型复杂度，预测各子过程指标的取值范围，并根据PPB与PPM，确定子过程指标是否满足项目要求。本发明方法基于UML提出的一种标准度量单位使得整个软件流程前后环节具有可预测性、可管理性，提高了估算的准确性；同时，为后期建立科学合理的PPB和PPM提供了保障。

Description

一种基于UML的量化项目资源控制方法

技术领域

本发明涉及软件过程控制技术，尤指一种基于统一建模语言（UML，Unified Modeling Language）的量化项目资源控制方法。

背景技术

项目资源控制是指在限定的资源条件下，通过估算完成项目目标。限定的资源可泛指人力、时间、工作范围、产品质量等。

现有对软件项目过程的估算有很多方法，常见的是代码行（LOC，Line ofCode）估算方法（简称LOC代码行）和功能点（FP）估算方法（简称FP功能点）。其中，

FP功能点以用户视角进行估算，一般在项目开始或者需求明确时使用，准确性比较高。但是，对于软件后期的设计、开发进行估算时，无法从技术角度进行准确的估算度量，误差比较大；LOC代码行以技术视角进行估算，对于项目本身的详细设计、编码等进行估算比较可观准确，但是，由于开发语言不同，开发人员水平不同，导致同一个功能得出的LOC代码行相差很大，如果在项目初期使用LOC进行估算，误差会更大。也就是说，FP功能点与LOC代码行均只在软件项目设计中的部分阶段才能达到估算的准确性，即FP功能点与LOC代码行，仅适用于软件生命周期的部分阶段，不能在全生命周期过程中发挥很好的作用，导致整个估算过程不准确。

过程性能基线（PPB）指软件过程及子过程输出(Y)，例如：需求开发缺陷注入率、需求评审缺陷移除率、软件设计缺陷注入率、软件测试缺陷移除率等。过程性能模型（PPM）指软件过程及子过程输出(Y)与输入(X)的定量关系，形式例如：Y=fuction(X1..Xn)，其中，X是使用GQIM方法识别确定的影响因子，例如：需求文档页数、代码行数、工作时间、测试覆盖率、人员工作年限等。基于已建立的PPB和PPM对软件过程进行量化控制。其中，GQIM表示目标（Goal）-问题（Questions）-指示器（Indicators）-度量点（Measure），是一种常用的软件度量方法。

软件流程中不同阶段的过程性能基线（PPB）与模型（PPM）应用的X值即影响因子不具有统一的标准，例如：在需求阶段，X的值可以是文档页数[Page]；在编码阶段，X的值可以是代码行数[LOC]。并且，目前，不同阶段使用不同的估算技术，例如：需求阶段使用FP估算方法；编码阶段使用LOC估算方法。基于以上2种条件，无法准确的建立PPB与PPM，更加无法达到软件过程量化控制的目标。

发明内容

为了解决上述技术问题，本发明提供了一种基于UML的量化项目资源控制方法，在整个资源控制中通用度量基本单位，能够使整个软件流程前后环节具有可预测性、可管理性。

为了达到本发明目的，本发明提供了一种基于统一建模语言UML的量化项目资源控制方法，包括：确定项目管理目标与影响因子，并识别出软件过程中各阶段的子过程指标及子影响因子；

根据历史项目数据识别出用于UML建模的影响因子；

根据识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML模型并估算UML模型复杂度；

根据识别出的子过程指标与子影响因子，建立软件过程中各阶段的过程性能基线PPB与模型PPM；

根据估算的UML模型复杂度，预测各子过程指标的取值范围，并根据PPB与PPM，确定子过程指标是否满足项目要求。

所述识别出软件过程中各阶段的子过程指标及子影响因子的方法为：

通过GQIM方法分解所述项目管理目标，形成项目管理过程中各阶段的所述子过程指标及子影响因子；其中，GQIM表示目标-问题-指示器-度量点。

所述建立软件过程中各阶段的UML模型并估算UML模型复杂度包括：

根据所述识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML图形；

根据预先设置的检验策略，对建立的软件过程中各阶段的UML图形进行校验，并根据预先设置的拆解策略，对通过校验的UML图形进行拆解；

根据预先设置的UML模型复杂度判定策略及拆解结果，估算UML模型复杂度。

所述UML图像包括：需求阶段的UML用例图；系统设计阶段的UML时序图；编码阶段的UML类图。

所述估算UML模型复杂度包括：

所述需求阶段的ULM用例图的复杂度CP_需求由用例个数和用户角色个数决定；

所述系统设计阶段的UML时序图的复杂度CP_设计由对象个数和对象间的交互次数决定；

所述编码阶段的UML类图的复杂度CP_编码由类的个数和所有类的方法个数决定。

所述建立软件过程中各阶段的过程性能基线PPB与模型PPM包括：

对所述识别出的子影响因子进行组合得到组合影响因子，确定子过程指标与组合影响因子的相关性；

判定具有相关性的子过程指标与组合影响因子的过程数据稳定后，对稳定的过程数据中的子过程指标与子影响因子进行正态校验；

对满足正态分布的子过程指标与组合影响因子进行回归分析以建立PPB与PPM。

所述确定子过程指标与组合影响因子的相关性包括：

使用散点图判断所述子过程指标与组合影响因子的相关性，若相关系数r大于预先设置的相关性阈值，则具有相关性。

所述判定具有相关性的子过程指标与组合影响因子的过程数据稳定包括：

使用控制图绘制所述子过程指标与组合影响因子的过程能力趋势，并按照预先设置的稳定策略判断其过程数据是否稳定。

所述满足正态分布为满足正态分布且无分组。

如果不满足正态分布，该方法还包括：

使用方差分析判断项目收集的数据是否具有明显分组性，如果具有明显分组行，则对不同组别的数据进行回归分析；

如果不具有分组特性，则返回所述根据历史项目数据识别出用于UML建模的影响因子，重新收集项目的数据。

与现有技术相比，本发明包括：确定项目管理目标与影响因子，并识别出软件过程中各阶段的子过程指标及子影响因子；根据历史项目数据识别出用于UML建模的影响因子；根据识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML模型并估算UML模型复杂度；根据识别出的子过程指标与子影响因子，建立软件过程中各阶段的过程性能基线(PPB)与模型(PPM)；根据估算的UML模型复杂度，预测各子过程指标的取值范围，并根据PPB与PPM，确定子过程指标是否满足项目要求。本发明方法基于UML提出的一种标准度量单位，即在整个资源控制中通用度量基本单位，使得整个软件流程前后环节具有可预测性、可管理性，提高了估算的准确性；同时，为后期建立科学合理的PPB和PPM提供了保障，从而更好地实现了软件过程的控制。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1为本发明基于UML的量化项目资源控制方法的流程图；

图2为本发明UML模型复杂度估算方法的实施例的流程示意图；

图3为本发明建立PPB与PPM的实施例的流程示意图；

图4为本发明以需求阶段为例的量化项目资源控制预测与控制实施例的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1为本发明基于UML的量化项目资源控制方法的流程图，如图1所示，包括以下步骤：

步骤100：确定项目管理目标与影响因子，并识别出软件过程中各阶段的子过程指标及子影响因子。

本步骤中，GQIM表示目标（Goal）-问题（Questions）-指示器（Indicators）-度量点（Measure），是一种常用的软件度量方法。GQIM方法主要流程大致包括：1.识别项目管理目标；2.针对识别出的目标，通过问答方式清晰定义解决的问题，这些问题需要关联到目标；3.针对识别的问题，定义度量指示器来展现识别的目标后者问题；4.针对度量指示器，识别基本的度量项，按照度量项的内容收集数据。具体实现属于本领域技术人员的惯用技术手段，这里不再赘述。

本发明中，使用GQIM识别出软件过程中各阶段的子过程指标及子影响因子的过程包括：1.识别目标：软件产品质量(Y)；2.定义问题：本文未提及，举例如：产品质量与哪些过程、人、工具有关，提升产品质量的方法有哪些等；3.定义度量指示器，比如对应本发明中的需求开发缺陷注入率(y1)、需求评审缺陷移除率(y2)、系统设计缺陷注入率(y3).等；4.识别度量项，比如对应本发明中的需求开发缺陷注入率(y1)的常见影响因子(x)，比如包括：本阶段工期(x1)、需求文档规模(x2)、需求开发人员数量(x3)、需求人员行业经验(x4)等。

常见的项目管理目标（Y）有客户满意度、软件产品质量、软件交付工期等。本发明实施例中，以软件产品质量为项目管理目标为例进行描述。

本步骤中，假设项目管理目标为软件产品质量，则，通过GQIM方法分解项目管理目标即软件产品质量，可以自动形成项目管理过程中各阶段的指标(y)与影响因子(x)如下：

软件产品质量的常见影响因子有缺陷的注入率(y)、缺陷的移除率(y)等。

与项目管理目标的影响因子相关的各阶段常见指标有：需求开发缺陷注入率(y1)、需求评审缺陷移除率(y2)、系统设计缺陷注入率(y3)、设计评审缺陷移除率(y4)、编码缺陷注入率(y5)、集成测试缺陷移除率(y6)、系统测试缺陷移除率(y7)等。其中，

需求开发缺陷注入率(y1)的常见影响因子(x)可以包括：本阶段工期(x1)、需求文档规模(x2)、需求开发人员数量(x3)、需求人员行业经验(x4)等。

需求评审缺陷移除率(y2)常见的影响因子(x)可以包括：本阶段工期(x1)、需求文档规模(x2)、需求评审人员数量(x3)、高级别评审人员比例(x4)等。

系统设计缺陷注入率(y3)常见的影响因子(x)可以包括：本阶段工期(x1)、概要设计文档规模(x2)、代码复用率(x3)、设计人员数量(x4)等。

设计评审缺陷移除率(y4)常见的影响因子(x)可以包括：本阶段工期(x1)、概要设计文档规模(x2)、设计评审人员数量(x3)等。

编码缺陷注入率(y5)常见的影响因子(x)可以包括：本阶段工期(x1)、详细设计文档规模(x2)、代码复用率(x3)、开发人员数量(x4)、开发水平(x5)等。

集成测试缺陷移除率(y6)常见的影响因子(x)可以包括：本阶段工期(x1)、概要设计文档规模(x2)、测试人员数量(x3)、测试覆盖率(x4)、自动化测试比例(x5)等。

系统测试缺陷移除率(y7)常见的影响因子(x)可以包括：本阶段工期(x1)、需求文档规模(x2)、测试人员数量(x3)、测试覆盖率(x4)、自动化测试比例(x5)等。

需要说明的是，本步骤中涉及到的项目管理目标（Y）与影响因子（X），以及各阶段的子过程指标（y）与子影响因子（x）都是根据项目的实际情况，使用GQIM方法识别出来的，不同的项目在实际使用中并不仅限于本步骤中涉及的参数，可根据项目的特点识别特定的过程指标与影响因子。本步骤中GQIM方法的具体实现属于本领域技术人员的惯用技术手段，这里不再赘述。

步骤101：根据历史项目数据识别出用于UML建模的影响因子。

根据步骤100中识别出的子过程指标（y）与子影响因子（x），收集历史项目数据。收集到的数据包括：可进行UML建模的数据、不可进行UML建模的数据两种。其中，不可进行UML建模的数据直接存储到数据库（命名为：MgtDB）中。

本步骤中，使用GQIM方法识别出不可进行UML建模的数据，将其直接存储在数据库MgtDB中；

而对于可进行UML建模的数据，如果数据库MgtDB中不存在该数据，则进入步骤102处理后，再将处理后的结果存入数据库MgtDB中；如果数据库MgtDB中已存在该数据，也进入步骤102处理后，再将处理后的实际结果存入数据库MgtDB中。

在本发明实施例中，需求文档规模、概要设计文档规模、详细设计文档规模三个子影响因子分别可以使用UML用例图、UML时序图、UML类图进行建模。

步骤102：根据识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML模型并估算UML模型复杂度。

本步骤包括：根据识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML图形；根据预先设置的检验策略，对建立的软件过程中各阶段的UML图形进行校验，并根据预先设置的拆解策略，对通过校验的UML图形进行拆解；根据预先设置的UML模型复杂度判定策略及拆解结果，估算UML模型复杂度。本步骤中的具体实现请参见图2。

步骤103：根据识别出的子过程指标与子影响因子，建立软件过程中各阶段的过程性能基线(PPB)与模型(PPM)。

本步骤包括：对识别出的子影响因子进行组合得到组合影响因子，确定子过程指标与组合影响因子的相关性；判定具有相关性的子过程指标与组合影响因子的过程数据稳定后，对稳定的过程数据中的子过程指标与子影响因子进行正态校验；对满足正态分布的子过程指标与组合影响因子进行回归分析以建立PPB与PPM。其中，如果满足正态分布的子过程指标与组合影响因子中存在多组分布，则所述回归分析为分别对不同组的数据进行回归分析。本步骤中的具体实现请参见图3。

步骤104：根据估算的UML模型复杂度，预测各子过程指标的取值范围，并根据PPB与PPM，确定子过程指标是否满足项目要求。本步骤即为量化项目管理预测与控制过程。具体实现参见图4。

通过本发明方法，会得到类似以下形式的过程性能模型(PPM):

Y=function(y1..yN)，其中Y为软件产品质量，y1..yN为各阶段缺陷注入率与移除率。

y1=fuction(x1..xN),其中y1为需求开发缺陷注入率，x1..xN为影响需求开发质量的因子。

y2=fuction(x1..xN),其中y2为需求评审缺陷移除率，x1..xN为影响需求评审质量的因子。

y3=fuction(x1..xN),其中y3为系统设计缺陷注入率，x1..xN为影响系统设计质量的因子。

y4=fuction(x1..xN),其中y4为设计评审缺陷移除率，x1..xN为影响设计评审质量的因子。

y5=fuction(x1..xN),其中y5为编码缺陷注入率，x1..xN为影响编码质量的因子。

y6=fuction(x1..xN),其中y6为集成测试缺陷移除率，x1..xN为影响集成测试质量的因子。

y7=fuction(x1..xN),其中y7为系统测试缺陷移除率，x1..xN为影响系统测试质量的因子。

本发明方法基于UML提出的一种标准度量单位，即在整个资源控制中通用度量基本单位，使得整个软件流程前后环节具有可预测性、可管理性，提高了估算的准确性；同时，为后期建立科学合理的PPB和PPM提供了保障，从而更好地实现了软件过程的控制。

具体地，本发明通过在软件项目的不同阶段采用不同的估算方法，如在需求分析阶段使用用例图进行模型复杂度估算；在系统设计阶段使用时序图进行模型复杂度估算；在编码阶段使用类图进行模型复杂度估算，既克服了FP功能点与LOC代码行均只在部分阶段估算准确性的弱点，又提供了一种全流程通用度量基本单位，使整个软件流程前后环节具有可预测性、可管理性。并且，本发明方法在统一度量单位标准的前提下，应用统计技术建立了组织过程性能基线（PPB）与模型（PPM）的流程方法，应用PPB与PPM实现了量化资源控制。

图2为本发明UML模型复杂度估算方法的实施例的流程示意图，如图2所示，包括：

步骤200：根据识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML图形。

UML建模是一个软件过程产物标准化的过程，本发明实施例中，即将模型复杂度估算需要使用到的需求文档、概要设计文档、详细设计文档的内容提供简单、一致、通用的说明，使开发者能在语义上取得一致，消除了因人而异的最佳表达方法所造成的影响。具体地，

在需求阶段，根据需求文档的内容，将需求用例转化为UML用例图，用例图从用户角度描述系统功能，并指出各功能的使用者。在用例图建模过程中的2个UML重要元素为用例和使用者；后续会对用例图进行校验及拆解，并去除其中重复的用例。

在系统设计阶段，根据设计文档的内容，将系统设计的逻辑实现转化为UML时序图，时序图展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模，说明系统的动态视图。在时序图建模过程中的2个UML重要元素为对象和消息，后续会对时序图进行校验及拆解，并去除其中重复的对象。

在编码阶段，根据详细设计文档的内容，将代码设计的逻辑实现转化为UML类图，类图描述系统中类的静态结构。在类图建模过程中的2个UML重要元素为类及类方法，后续会对类图进行校验及拆解，并去除其中重复的类。

步骤201：根据预先设置的检验策略，对建立的软件过程中各阶段的UML图形进行校验，并根据预先设置的拆解策略，对通过校验的UML图形进行拆解。

根据预先设置的检验策略，判断UML图形是否满足建模要求，若满足要求，则在Word文档中将该UML图形标记为真（True），即表示校验通过；否则标记为假（False），即表示校验未通过，并记录未通过原因，使项目建模人员后续过程进行针对性的修正。

其中，校验策略可以是：对于UML用例图：至少有1个使用者；至少有3个用例；对于UML时序图：至少有2个对象；至少有2个调用消息；对于UML类图：至少有4个类；单个类中除构造方法外，至少有1个方法。这里仅仅是对校验策略进行举例说明，并不用于限定校验策略，校验策略可根据项目实际需求设置。

对于本步骤中通过校验的，标记为True的UML图形，根据预先设置的拆解策略对通过校验的UML图形进行拆解，将UML图形拆解后的结果存储到数据库MgtDB中。

其中，拆解策略可以是：对于UML用例图：重复的使用者看作同一用户，计数为1；相同的用例依然看作不同用例，计数为N；3级扩展用例可忽略，计数为0；对于UML时序图：重复的对象看作同一对象，计数为1；同一对象自身的调用消息可忽略，计数为0；2个对象间相同的调用消息看作不同消息，计数为N；对于UML类图：重复的类看作同一个类，计数为1；同一类中名字相同的方法看作同一方法，计数为1；不同类中名字相同的方法看作不同的方法，计数为N。这里仅仅是对拆解策略进行举例说明，并不用于限定拆解策略，拆解策略可根据项目实际需求设置。

步骤202：根据预先设置的UML模型复杂度判定策略及拆解结果，估算UML模型复杂度。

根据预先设置的UML模型复杂度判定策略及拆解结果，按照以下公式计算各阶段UML模型复杂度。其中，假设UML模型复杂度判定策略如表1所示。

表1

需求阶段的ULM用例图复杂度(CP_需求)，由用例个数和用户角色个数共同决定，如公式(1)所示：

CP_需求=用例个数×用户角色个数×CO_需求    (1)

系统设计阶段的UML时序图复杂度(CP_设计)，由对象个数和对象间的交互次数共同决定，如公式(2)所示：

CP_设计=对象个数×对象间的交互次数×CO_设计    (2)

编码阶段的UML类图复杂度(CP_编码)，由类的个数和所有类的方法个数共同决定，如公式(3)所示：

CP_编码=类的个数×类中方法数×CO_编码    (3)

上述公式中，模型复杂度用CP表示，单位为ul。调整系数用CO表示，一般由历史项目经验估算得出，比如CO_需求:CO_设计:CO_编码=1：2.5：6。其中，ul为元数，是本申请UML计算中的单位，类似于长度的单位米（m）。

图3为本发明建立PPB与PPM的实施例的流程示意图，如图3所示，包括以下步骤：

步骤300：对识别出的子影响因子进行组合得到组合影响因子。

使用数学方法即组合将步骤100中识别出的子影响因子(x)进行组合，组合结果为X_组N。

步骤301：确定子过程指标与组合影响因子的相关性，当二者具有相关性时进入步骤302；否则返回步骤300。

本步骤中，使用散点图判断子过程指标(y)与组合影响因子(X_组N)的相关性，若相关系数r大于预先设置的相关性阈值，比如0.75，则说明具有相关性，相关性很强，将子过程指标(y)与组合影响因子(X_组N)的组合写入数据库MgtDB中。其中相关性阈值可根据实际情况自行设置；其中，散点图用于对两个变量进行相关性分析，具体实现属于本领域技术人员的惯用技术手段，这里不再赘述。

如果相关系数r不大于预先设置的相关性阈值，则返回步骤300，不断尝试子过程指标(y)与组合影响因子(X_组N)的所有组合，并将满足相关性条件的写入数据库MgtDB中。

步骤302：判断具有相关性的子过程指标与组合影响因子的过程数据是否稳定，如果稳定则进入步骤303；否则进入步骤306。

本步骤中，可以使用控制图绘制子过程指标(y)与组合影响因子(X_组N)的过程能力趋势，并按照预先设置的稳定策略判断其过程数据是否稳定。其中，控制图用于判断过程数据是否稳定，具体实现属于本领域技术人员的惯用技术手段，这里不再赘述。

其中，稳定策略可以为：

满足下列其中一条策略的，则说明过程数据有异常：点在控制线外或者线上；或者，控制线内的点排列不随机；或者，大多数点靠近控制线界限；或者，大多数点集中在中心线附近；或者，连续不少于6个点有上升或者下降的倾向等。

步骤303：对稳定的过程数据中的子过程指标与子影响因子进行正态校验，当不满足正态分布时，进入步骤306；当满足正态分布且无分组时，进入步骤304；当满足正态分布且存在多组分布时，进入步骤307。

本步骤中，正态校验的具体实现属于本领域技术人员的惯用技术手段。这里不再赘述。需要说明的是，本步骤中，当正态分布的P值大于预先设置的门限值，如0.05时，说明项目收集的数据满足正态分布，并且来自同一个种群；其中预先设置的门限值可根据实际情况自行设置；

如果项目收集的数据不满足正态分布，则使用方差分析判断项目收集的数据是否来自不同种群，即是否具有明显分组性，如果具有明显分组行，则进入步骤307；

如果不具有分组特性，则进入步骤306，即从步骤101开始重新收集项目的数据。

步骤304：对满足正态分布的子过程指标与组合影响因子进行回归分析。

步骤305：建立PPB与PPM。结束本流程。

本步骤中使用回归分析的结果是PPM，即表3中的回归公式。

如果在步骤302中判断出过程稳定，在步骤302中产生的数据如表3中的上限、均值、下限就可以理解为PPB，如表2所示：

表2

本步骤中，将得到的回归结果写入到数据库MgtDB中。

步骤306：重新收集子过程指标与子影响因子，即返回步骤101重新执行。结束本流程。

步骤307：对不同组别的数据进行回归分析，并生成y=function(x1..xN)形式的回归公式，之后返回步骤305。

本发明实施例中，以需求阶段为例，其生成的PPB与PPM示例如表3所示：

表3

表3以需求阶段为例，其中的结果可以为后续需求阶段的需求分析与需求评审提供子过程的预测与控制依据，并且可依据图3中的描述的步骤进行操作，计算得到其他子过程，比如包括：系统设计阶段、编码阶段、集成测试阶段、测试阶段（泛指系统测试、验收测试等）等的PPB与PPM。

图4为本发明以需求阶段为例的量化项目资源控制预测与控制实施例的流程示意图，如图4所示，具体包括：

需求开发过程，

在需求开发前，从数据库MgtDB中获取需求开发过程的子过程指标如缺陷注入率y1的PPM，如表2所示，y1=0.241+0.319×x1-0.0571×x2，在已知的影响因子x1需求用例模型复杂度、影响因子x2需求开发人员行业经验的前提下，使用蒙特卡罗模拟分析方法，可以预测缺陷注入率y1的取值范围。

如果缺陷注入率y1的取值范围在需求开发过程的PPB范围内，并且满足项目要求，则接受该预测结果，并且达到了需求开发前预测缺陷注入率的目标；

如果缺陷注入率y1的取值范围在需求开发过程的PPB范围之外，则说明需求开发缺陷注入率过大，在现有组织能力的情况下，后续过程可预测的缺陷移除率内，项目最终交付的缺陷数将大于项目目标。要是项目组接受该风险，则暂不处理，否则需要结合实际情况调整影响因子x1与影响因子x2的能力，以便量化控制缺陷注入率，完成项目预期目标。

需要说明的是，本发明实施例中并未包含子过程工期（SPD）的性能基线(PPB)与模型(PPM)，其建立过程可采用本发明图1所示的方法，本领域技术人员按照图1所示的方法是容易实现的，这里不在赘述。

在需求开发后，已可准确度量出当前SPD，判断是否在子过程工期性能基线(PPB)范围内，若偏差较大，则需要调整项目后续的子过程。

需求评审过程，

在需求评审前，从数据库MgtDB中获取需求评审过程的子过程指标如缺陷率y2的PPM，如表2所示，y2=-6.82+0.177×x1+0.101×x2+13.6×x3，在已知的影响因子x1需求评审投入工作量、影响因子x2需求用例模型复杂度、影响因子x3需求评审高级别人员比例的前提下，使用蒙特卡罗模拟分析方法，可以预测缺陷率y2的取值范围。

如果缺陷率y2的取值范围在需求评审过程的PPB范围内，并且满足项目要求，则接受该预测结果，并且达到了需求评审前缺陷移除率的预测目标；

如果缺陷率y2的取值范围在需求评审过程的PPB范围之外，则说明需求评审缺陷移除率不足，在现有组织能力的情况下，后续过程可预测的缺陷移除率内，项目最终交付的缺陷数将大于项目目标。要是项目组接受该风险，则暂不处理，否则需要结合实际情况调整影响因子x1、影响因子x2与影响因子x3的能力，以便于量化控制缺陷移除率，完成项目预期目标。

在需求评审后，已可准确度量出当前SPD，判断是否在子过程工期性能基线(PPB)范围内，若偏差较大，则需要调整项目后续的子过程。

在需求评审后，已可准确度量出需求评审的缺陷移除率，若此时的缺陷移除率不在组织的需求评审过程性能基线(PPB)范围内，说明需求评审的效果不理想，需要分析原因，采取新的方法重新进行需求评审，达到事后控制的作用。若不采取任何措施，可根据当前需求评审阶段缺陷移除率过低的现象，推测出后续过程需提升缺陷移除率的影响因子x能力以提升缺陷移除率，否则在项目交付时可能交付比预期目标更多的缺陷。

图4中，仅以需求阶段为例进行说明，在软件过程的其他阶段，如设计阶段、编码阶段、测试阶段可参见图4所述进行操作，也可以达到项目各子阶段的预测与控制。

本发明上述内容主要以缺陷的注入率、缺陷移除率、子过程工期为例进行描述，在步骤100～步骤103的过程中，如果识别出了不同的项目目标、子过程指标及影响因子，按照图1所示步骤进行，即可得到不同的过程性能基线（PPB）与模型（PPM），并且对项目各子阶段的预测与控制，实现量化项目管理。

虽然本发明所揭露的实施方式如上，但所述的内容仅为便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (10)

1.一种基于统一建模语言UML的量化项目资源控制方法，其特征在于，包括：确定项目管理目标与影响因子，并识别出软件过程中各阶段的子过程指标及子影响因子；

根据历史项目数据识别出用于UML建模的影响因子；

根据识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML模型并估算UML模型复杂度；

根据识别出的子过程指标与子影响因子，建立软件过程中各阶段的过程性能基线PPB与模型PPM；

根据估算的UML模型复杂度，预测各子过程指标的取值范围，并根据PPB与PPM，确定子过程指标是否满足项目要求。

2.根据权利要求1所述的量化项目资源控制方法，其特征在于，所述识别出软件过程中各阶段的子过程指标及子影响因子的方法为：

通过GQIM方法分解所述项目管理目标，形成项目管理过程中各阶段的所述子过程指标及子影响因子；其中，GQIM表示目标-问题-指示器-度量点。

3.根据权利要求1所述的量化项目资源控制方法，其特征在于，所述建立软件过程中各阶段的UML模型并估算UML模型复杂度包括：

根据所述识别出的各阶段的子过程指标及子影响因子，建立软件过程中各阶段的UML图形；

根据预先设置的检验策略，对建立的软件过程中各阶段的UML图形进行校验，并根据预先设置的拆解策略，对通过校验的UML图形进行拆解；

根据预先设置的UML模型复杂度判定策略及拆解结果，估算UML模型复杂度。

4.根据权利要求3所述的量化项目资源控制方法，其特征在于，所述UML图像包括：需求阶段的UML用例图；系统设计阶段的UML时序图；编码阶段的UML类图。

5.根据权利要求4所述的量化项目资源控制方法，其特征在于，所述估算UML模型复杂度包括：

所述需求阶段的ULM用例图的复杂度CP_需求由用例个数和用户角色个数决定；

所述系统设计阶段的UML时序图的复杂度CP_设计由对象个数和对象间的交互次数决定；

所述编码阶段的UML类图的复杂度CP_编码由类的个数和所有类的方法个数决定。

6.根据权利要求1或2或3所述的量化项目资源控制方法，其特征在于，所述建立软件过程中各阶段的过程性能基线PPB与模型PPM包括：

对所述识别出的子影响因子进行组合得到组合影响因子，确定子过程指标与组合影响因子的相关性；

判定具有相关性的子过程指标与组合影响因子的过程数据稳定后，对稳定的过程数据中的子过程指标与子影响因子进行正态校验；

对满足正态分布的子过程指标与组合影响因子进行回归分析以建立PPB与PPM。

7.根据权利要求6所述的量化项目资源控制方法，其特征在于，所述确定子过程指标与组合影响因子的相关性包括：

使用散点图判断所述子过程指标与组合影响因子的相关性，若相关系数r大于预先设置的相关性阈值，则具有相关性。

8.根据权利要求6所述的量化项目资源控制方法，其特征在于，所述判定具有相关性的子过程指标与组合影响因子的过程数据稳定包括：

使用控制图绘制所述子过程指标与组合影响因子的过程能力趋势，并按照预先设置的稳定策略判断其过程数据是否稳定。

9.根据权利要求6所述的量化项目资源控制方法，其特征在于，所述满足正态分布为满足正态分布且无分组。

10.根据权利要求9所述的量化项目资源控制方法，其特征在于，如果不满足正态分布，该方法还包括：

使用方差分析判断项目收集的数据是否具有明显分组性，如果具有明显分组行，则对不同组别的数据进行回归分析；

如果不具有分组特性，则返回所述根据历史项目数据识别出用于UML建模的影响因子，重新收集项目的数据。

Images