[发明专利]一种基于UML的量化项目资源控制方法

说明书

技术领域

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

背景技术

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

现有对软件项目过程的估算有很多方法，常见的是代码行（LOC，Line of Code）估算方法（简称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_设计由对象个数和对象间的交互次数决定；