一種基于uml的量化項目資源控制方法
【專利摘要】本發(fā)明公開了一種基于UML的量化項目資源控制方法，包括確定項目管理目標與影響因子，并識別出軟件過程中各階段的子過程指標及子影響因子；根據歷史項目數據識別出用于UML建模的影響因子；根據識別出的各階段的子過程指標及子影響因子，建立軟件過程中各階段的UML模型并估算UML模型復雜度；根據識別出的子過程指標與子影響因子，建立軟件過程中各階段的過程性能基線(PPB)與模型(PPM)；根據估算的UML模型復雜度，預測各子過程指標的取值范圍，并根據PPB與PPM，確定子過程指標是否滿足項目要求。本發(fā)明方法基于UML提出的一種標準度量單位使得整個軟件流程前后環(huán)節(jié)具有可預測性、可管理性，提高了估算的準確性；同時，為后期建立科學合理的PPB和PPM提供了保障。
【專利說明】一種基于UML的量化項目資源控制方法
【技術領域】
[0001]本發(fā)明涉及軟件過程控制技術，尤指一種基于統(tǒng)一建模語言(UML，Unified Modeling Language)的量化項目資源控制方法。
【背景技術】
[0002]項目資源控制是指在限定的資源條件下，通過估算完成項目目標。限定的資源可 泛指人力、時間、工作范圍、產品質量等。
[0003]現(xiàn)有對軟件項目過程的估算有很多方法，常見的是代碼行(L0C，Line of Code)估 算方法(簡稱LOC代碼行)和功能點(FP)估算方法(簡稱FP功能點)。其中，
[0004]FP功能點以用戶視角進行估算，一般在項目開始或者需求明確時使用，準確性比 較高。但是，對于軟件后期的設計、開發(fā)進行估算時，無法從技術角度進行準確的估算度量， 誤差比較大；L0C代碼行以技術視角進行估算，對于項目本身的詳細設計、編碼等進行估算 比較可觀準確，但是，由于開發(fā)語言不同，開發(fā)人員水平不同，導致同一個功能得出的LOC 代碼行相差很大，如果在項目初期使用LOC進行估算，誤差會更大。也就是說，F(xiàn)P功能點與 LOC代碼行均只在軟件項目設計中的部分階段才能達到估算的準確性，即FP功能點與LOC 代碼行，僅適用于軟件生命周期的部分階段，不能在全生命周期過程中發(fā)揮很好的作用，導 致整個估算過程不準確。
[0005]過程性能基線(PPB)指軟件過程及子過程輸出(Y)，例如:需求開發(fā)缺陷注入率、 需求評審缺陷移除率、軟件設計缺陷注入率、軟件測試缺陷移除率等。過程性能模型(PPM) 指軟件過程及子過程輸出(Y)與輸入(X)的定量關系，形式例如:Y=fUCtion(Xl..Xn)，其 中，X是使用GQIM方法識別確定的影響因子，例如:需求文檔頁數、代碼行數、工作時間、測 試覆蓋率、人員工作年限等?；谝呀⒌腜PB和PPM對軟件過程進行量化控制。其中， GQIM 表不目標(Goal)-問題(Questions) -指不器(Indicators)-度量點(Measure),是一 種常用的軟件度量方法。
[0006]軟件流程中不同階段的過程性能基線(PPB)與模型(PPM)應用的X值即影響因子 不具有統(tǒng)一的標準，例如:在需求階段，X的值可以是文檔頁數[Page];在編碼階段，X的值 可以是代碼行數[L0C]。并且，目前，不同階段使用不同的估算技術，例如:需求階段使用FP 估算方法；編碼階段使用LOC估算方法?；谝陨?種條件，無法準確的建立PPB與PPM， 更加無法達到軟件過程量化控制的目標。

【發(fā)明內容】

[0007]為了解決上述技術問題，本發(fā)明提供了一種基于UML的量化項目資源控制方法， 在整個資源控制中通用度量基本單位，能夠使整個軟件流程前后環(huán)節(jié)具有可預測性、可管 理性。
[0008]為了達到本發(fā)明目的，本發(fā)明提供了一種基于統(tǒng)一建模語言UML的量化項目資源 控制方法，包括:確定項目管理目標與影響因子，并識別出軟件過程中各階段的子過程指標及子影響因子；
[0009]根據歷史項目數據識別出用于UML建模的影響因子；
[0010]根據識別出的各階段的子過程指標及子影響因子，建立軟件過程中各階段的UML模型并估算UML模型復雜度；
[0011]根據識別出的子過程指標與子影響因子，建立軟件過程中各階段的過程性能基線PPB與模型PPM ；
[0012]根據估算的UML模型復雜度，預測各子過程指標的取值范圍，并根據PPB與PPM，確定子過程指標是否滿足項目要求。
[0013]所述識別出軟件過程中各階段的子過程指標及子影響因子的方法為:
[0014]通過GQM方法分解所述項目管理目標，形成項目管理過程中各階段的所述子過程指標及子影響因子；其中，GQIM表示目標-問題-指示器-度量點。
[0015]所述建立軟件過程中各階段的UML模型并估算UML模型復雜度包括:
[0016]根據所述識別出的各階段的子過程指標及子影響因子，建立軟件過程中各階段的UML圖形；
[0017]根據預先設置的檢驗策略，對建立的軟件過程中各階段的UML圖形進行校驗，并根據預先設置的拆解策略，對通過校驗的UML圖形進行拆解；
[0018]根據預先設置的UML模型復雜度判定策略及拆解結果，估算UML模型復雜度。
[0019]所述UML圖像包括:需求階段的UML用例圖；系統(tǒng)設計階段的UML時序圖；編碼階段的UML類圖。
[0020]所述估算UML模型復雜度包括:
[0021]所述需求階段的ULM用例圖的復雜度CP 由用例個數和用戶角色個數決定；
[0022]所述系統(tǒng)設計階段的UML時序圖的復雜度CPsit由對象個數和對象間的交互次數決定;
[0023]所述編碼階段的UML類圖的復雜度CP由類的個數和所有類的方法個數決定。
[0024]所述建立軟件過程中各階段的過程性能基線PPB與模型PPM包括:
[0025]對所述識別出的子影響因子進行組合得到組合影響因子，確定子過程指標與組合影響因子的相關性；
[0026]判定具有相關性的子過程指標與組合影響因子的過程數據穩(wěn)定后，對穩(wěn)定的過程數據中的子過程指標與子影響因子進行正態(tài)校驗；
[0027]對滿足正態(tài)分布的子過程指標與組合影響因子進行回歸分析以建立PPB與PPM。
[0028]所述確定子過程指標與組合影響因子的相關性包括:
[0029]使用散點圖判斷所述子過程指標與組合影響因子的相關性，若相關系數r大于預先設置的相關性閾值，則具有相關性。
[0030]所述判定具有相關性的子過程指標與組合影響因子的過程數據穩(wěn)定包括:
[0031]使用控制圖繪制所述子過程指標與組合影響因子的過程能力趨勢，并按照預先設置的穩(wěn)定策略判斷其過程數據是否穩(wěn)定。
[0032]所述滿足正態(tài)分布為滿足正態(tài)分布且無分組。
[0033]如果不滿足正態(tài)分布，該方法還包括:
[0034]使用方差分析判斷項目收集的數據是否具有明顯分組性，如果具有明顯分組行，則對不同組別的數據進行回歸分析；
[0035]如果不具有分組特性，則返回所述根據歷史項目數據識別出用于UML建模的影響 因子，重新收集項目的數據。
[0036]與現(xiàn)有技術相比，本發(fā)明包括:確定項目管理目標與影響因子，并識別出軟件過程 中各階段的子過程指標及子影響因子；根據歷史項目數據識別出用于UML建模的影響因 子；根據識別出的各階段的子過程指標及子影響因子，建立軟件過程中各階段的UML模型 并估算UML模型復雜度；根據識別出的子過程指標與子影響因子，建立軟件過程中各階段 的過程性能基線(PPB)與模型(PPM);根據估算的UML模型復雜度，預測各子過程指標的取 值范圍，并根據PPB與PPM，確定子過程指標是否滿足項目要求。本發(fā)明方法基于UML提出 的一種標準度量單位，即在整個資源控制中通用度量基本單位，使得整個軟件流程前后環(huán) 節(jié)具有可預測性、可管理性，提高了估算的準確性；同時，為后期建立科學合理的PPB和PPM 提供了保障，從而更好地實現(xiàn)了軟件過程的控制。
[0037]本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變 得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在說明書、權利 要求書以及附圖中所特別指出的結構來實現(xiàn)和獲得。
【專利附圖】

【附圖說明】
[0038]附圖用來提供對本發(fā)明技術方案的進一步理解，并且構成說明書的一部分，與本 申請的實施例一起用于解釋本發(fā)明的技術方案，并不構成對本發(fā)明技術方案的限制。
[0039]圖1為本發(fā)明基于UML的量化項目資源控制方法的流程圖；
[0040]圖2為本發(fā)明UML模型復雜度估算方法的實施例的流程示意圖；
[0041 ] 圖3為本發(fā)明建立PPB與PPM的實施例的流程示意圖；
[0042]圖4為本發(fā)明以需求階段為例的量化項目資源控制預測與控制實施例的流程示 意圖。
【具體實施方式】
[0043]為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白，下文中將結合附圖對本發(fā)明 的實施例進行詳細說明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中 的特征可以相互任意組合。
[0044]在附圖的流程圖示出的步驟可以在諸如一組計算機可執(zhí)行指令的計算機系統(tǒng)中 執(zhí)行。并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同于此處的順 序執(zhí)行所示出或描述的步驟。
[0045]圖1為本發(fā)明基于UML的量化項目資源控制方法的流程圖，如圖1所示，包括以下 步驟:
[0046]步驟100:確定項目管理目標與影響因子，并識別出軟件過程中各階段的子過程 指標及子影響因子。
[0047]本步驟中，GQIM表不目標(Goal)-問題(Questions)-指不器(Indicators)-度 量點(Measure)，是一種常用的軟件度量方法。GQ頂方法主要流程大致包括:1.識別項目管 理目標；2.針對識別出的目標，通過問答方式清晰定義解決的問題，這些問題需要關聯(lián)到目標；3.針對識別的問題，定義度量指示器來展現(xiàn)識別的目標后者問題；4.針對度量指示器，識別基本的度量項，按照度量項的內容收集數據。具體實現(xiàn)屬于本領域技術人員的慣用技術手段，這里不再贅述。
[0048]本發(fā)明中，使用GQ頂識別出軟件過程中各階段的子過程指標及子影響因子的過程包括:1.識別目標:軟件產品質量(Y) ；2.定義問題:本文未提及，舉例如:產品質量與哪些過程、人、工具有關，提升產品質量的方法有哪些等；3.定義度量指示器，比如對應本發(fā)明中的需求開發(fā)缺陷注入率(yl)、需求評審缺陷移除率(y2)、系統(tǒng)設計缺陷注入率(y3).等；4.識別度量項，比如對應本發(fā)明中的需求開發(fā)缺陷注入率(yl)的常見影響因子(X)，比如包括:本階段工期(xl)、需求文檔規(guī)模(x2)、需求開發(fā)人員數量(x3)、需求人員行業(yè)經驗(x4)等。
[0049]常見的項目管理目標(Y)有客戶滿意度、軟件產品質量、軟件交付工期等。本發(fā)明實施例中，以軟件產品質量為項目管理目標為例進行描述。
[0050]本步驟中，假設項目管理目標為軟件產品質量，則，通過GQM方法分解項目管理目標即軟件產品質量，可以自動形成項目管理過程中各階段的指標(y)與影響因子(X)如下:
[0051]軟件產品質量的常見影響因子有缺陷的注入率ω、缺陷的移除率ω等。
[0052]與項目管理目標的影響因子相關的各階段常見指標有:需求開發(fā)缺陷注入率(yl)、需求評審缺陷移除率(y2)、系統(tǒng)設計缺陷注入率(y3)、設計評審缺陷移除率(y4)、編碼缺陷注入率(y5)、集成測試缺陷移除率(y6)、系統(tǒng)測試缺陷移除率(y7)等。其中，
[0053]需求開發(fā)缺陷注入率(yl)的常見影響因子(X)可以包括:本階段工期(xl)、需求文檔規(guī)模(x2)、需求開發(fā)人員數量(x3)、需求人員行業(yè)經驗(x4)等。
[0054]需求評審缺陷移除率(y2)常見的影響因子(X)可以包括:本階段工期(xl)、需求文檔規(guī)模(x2)、需求評審人員數量(x3)、高級別評審人員比例(x4)等。
[0055]系統(tǒng)設計缺陷注入率(y3)常見的影響因子(X)可以包括:本階段工期(xl)、概要設計文檔規(guī)模(x2)、代碼復用率(x3)、設計人員數量(x4)等。
[0056]設計評審缺陷移除率(y4)常見的影響因子(X)可以包括:本階段工期(xl)、概要設計文檔規(guī)模(x2)、設計評審人員數量(x3)等。
[0057]編碼缺陷注入率(y5)常見的影響因子(X)可以包括:本階段工期(xl)、詳細設計文檔規(guī)模(x2)、代碼復用率(x3)、開發(fā)人員數量(x4)、開發(fā)水平(x5)等。
[0058]集成測試缺陷移除率(y6)常見的影響因子(X)可以包括:本階段工期(xl)、概要設計文檔規(guī)模(x2)、測試人員數量(x3)、測試覆蓋率(x4)、自動化測試比例(x5)等。
[0059]系統(tǒng)測試缺陷移除率(y7)常見的影響因子(X)可以包括:本階段工期(xl)、需求文檔規(guī)模(x2)、測試人員數量(x3)、測試覆蓋率(x4)、自動化測試比例(x5)等。
[0060]需要說明的是，本步驟中涉及到的項目管理目標(Y)與影響因子(X)，以及各階段的子過程指標(y)與子影響因子(X)都是根據項目的實際情況，使用GQIM方法識別出來的，不同的項目在實際使用中并不僅限于本步驟中涉及的參數，可根據項目的特點識別特定的過程指標與影響因子。本步驟中GQIM方法的具體實現(xiàn)屬于本領域技術人員的慣用技術手段，這里不再贅述。
[0061]步驟101:根據歷史項目數據識別出用于UML建模的影響因子。[0062]根據步驟100中識別出的子過程指標(y)與子影響因子(X)，收集歷史項目數據。 收集到的數據包括:可進行UML建模的數據、不可進行UML建模的數據兩種。其中，不可進 行UML建模的數據直接存儲到數據庫(命名為:MgtDB)中。
[0063]本步驟中，使用GQIM方法識別出不可進行UML建模的數據，將其直接存儲在數據 庫MgtDB中；
[0064]而對于可進行UML建模的數據，如果數據庫MgtDB中不存在該數據，則進入步驟 102處理后，再將處理后的結果存入數據庫MgtDB中；如果數據庫MgtDB中已存在該數據， 也進入步驟102處理后，再將處理后的實際結果存入數據庫MgtDB中。
[0065]在本發(fā)明實施例中，需求文檔規(guī)模、概要設計文檔規(guī)模、詳細設計文檔規(guī)模三個子 影響因子分別可以使用UML用例圖、UML時序圖、UML類圖進行建模。
[0066]步驟102:根據識別出的各階段的子過程指標及子影響因子，建立軟件過程中各 階段的UML模型并估算UML模型復雜度。
[0067]本步驟包括:根據識別出的各階段的子過程指標及子影響因子，建立軟件過程中 各階段的UML圖形；根據預先設置的檢驗策略，對建立的軟件過程中各階段的UML圖形進行 校驗，并根據預先設置的拆解策略，對通過校驗的UML圖形進行拆解；根據預先設置的UML 模型復雜度判定策略及拆解結果，估算UML模型復雜度。本步驟中的具體實現(xiàn)請參見圖2。
[0068]步驟103:根據識別出的子過程指標與子影響因子，建立軟件過程中各階段的過 程性能基線(PPB)與模型(PPM)。
[0069]本步驟包括:對識別出的子影響因子進行組合得到組合影響因子，確定子過程指 標與組合影響因子的相關性；判定具有相關性的子過程指標與組合影響因子的過程數據穩(wěn) 定后，對穩(wěn)定的過程數據中的子過程指標與子影響因子進行正態(tài)校驗；對滿足正態(tài)分布的 子過程指標與組合影響因子進行回歸分析以建立PPB與PPM。其中，如果滿足正態(tài)分布的子 過程指標與組合影響因子中存在多組分布，則所述回歸分析為分別對不同組的數據進行回 歸分析。本步驟中的具體實現(xiàn)請參見圖3。
[0070]步驟104:根據估算的UML模型復雜度，預測各子過程指標的取值范圍，并根據PPB 與PPM，確定子過程指標是否滿足項目要求。本步驟即為量化項目管理預測與控制過程。具 體實現(xiàn)參見圖4。
[0071]通過本發(fā)明方法，會得到類似以下形式的過程性能模型(PPM):
[0072]Y=function(yl..yN)，其中Y為軟件產品質量，yl..yN為各階段缺陷注入率與移除率。
[0073]yl=fuction (xl..xN),其中yl為需求開發(fā)缺陷注入率,xl..xN為影響需求開發(fā)質 量的因子。
[0074]y2=fuction (xl..xN),其中y2為需求評審缺陷移除率,xl..xN為影響需求評審質 量的因子。
[0075]y3=fuction (xl..xN),其中y3為系統(tǒng)設計缺陷注入率,xl..xN為影響系統(tǒng)設計質 量的因子。
[0076]y4=fuction (xl..xN),其中y4為設計評審缺陷移除率,xl..xN為影響設計評審質 量的因子。
[0077]y5=fuction (xl..xN),其中y5為編碼缺陷注入率，xl..xN為影響編碼質量的因子。
[0078]y6=fuction (xl..xN),其中y6為集成測試缺陷移除率,xl..xN為影響集成測試質量的因子。
[0079]y7=fuction (xl..xN),其中y7為系統(tǒng)測試缺陷移除率,xl..xN為影響系統(tǒng)測試質量的因子。
[0080]本發(fā)明方法基于UML提出的一種標準度量單位，即在整個資源控制中通用度量基本單位，使得整個軟件流程前后環(huán)節(jié)具有可預測性、可管理性，提高了估算的準確性；同時，為后期建立科學合理的PPB和PPM提供了保障，從而更好地實現(xiàn)了軟件過程的控制。
[0081]具體地，本發(fā)明通過在軟件項目的不同階段采用不同的估算方法，如在需求分析階段使用用例圖進行模型復雜度估算；在系統(tǒng)設計階段使用時序圖進行模型復雜度估算；在編碼階段使用類圖進行模型復雜度估算，既克服了 FP功能點與LOC代碼行均只在部分階段估算準確性的弱點，又提供了一種全流程通用度量基本單位，使整個軟件流程前后環(huán)節(jié)具有可預測性、可管理性。并且，本發(fā)明方法在統(tǒng)一度量單位標準的前提下，應用統(tǒng)計技術建立了組織過程性能基線(PPB)與模型(PPM)的流程方法，應用PPB與PPM實現(xiàn)了量化資源控制。
[0082]圖2為本發(fā)明UML模型復雜度估算方法的實施例的流程示意圖，如圖2所示，包括:
[0083]步驟200:根據識別出的各階段的子過程指標及子影響因子，建立軟件過程中各階段的UML圖形。
[0084]UML建模是一個軟件過程產物標準化的過程，本發(fā)明實施例中，即將模型復雜度估算需要使用到的需求文檔、概要設計文檔、詳細設計文檔的內容提供簡單、一致、通用的說明，使開發(fā)者能在語義上取得一致，消除了因人而異的最佳表達方法所造成的影響。具體地，
[0085]在需求階段，根據需求文檔的內容，將需求用例轉化為UML用例圖，用例圖從用戶角度描述系統(tǒng)功能，并指出各功能的使用者。在用例圖建模過程中的2個UML重要元素為用例和使用者；后續(xù)會對用例圖進行校驗及拆解，并去除其中重復的用例。
[0086]在系統(tǒng)設計階段，根據設計文檔的內容，將系統(tǒng)設計的邏輯實現(xiàn)轉化為UML時序圖，時序圖展現(xiàn)了一組對象和由這組對象收發(fā)的消息，用于按時間順序對控制流建模，說明系統(tǒng)的動態(tài)視圖。在時序圖建模過程中的2個UML重要元素為對象和消息，后續(xù)會對時序圖進行校驗及拆解，并去除其中重復的對象。
[0087]在編碼階段，根據詳細設計文檔的內容，將代碼設計的邏輯實現(xiàn)轉化為UML類圖，類圖描述系統(tǒng)中類的靜態(tài)結構。在類圖建模過程中的2個UML重要元素為類及類方法，后續(xù)會對類圖進行校驗及拆解，并去除其中重復的類。
[0088]步驟201:根據預先設置的檢驗策略，對建立的軟件過程中各階段的UML圖形進行校驗，并根據預先設置的拆解策略，對通過校驗的UML圖形進行拆解。
[0089]根據預先設置的檢驗策略，判斷UML圖形是否滿足建模要求，若滿足要求，則在Word文檔中將該UML圖形標記為真(True)，即表示校驗通過；否則標記為假(False)，即表示校驗未通過，并記錄未通過原因，使項目建模人員后續(xù)過程進行針對性的修正。
[0090]其中，校驗策略可以是:對于UML用例圖:至少有I個使用者；至少有3個用例；對于UML時序圖:至少有2個對象；至少有2個調用消息；對于UML類圖:至少有4個類；單個類中除構造方法外，至少有I個方法。這里僅僅是對校驗策略進行舉例說明，并不用于限定校驗策略，校驗策略可根據項目實際需求設置。
[0091]對于本步驟中通過校驗的，標記為True的UML圖形，根據預先設置的拆解策略對通過校驗的UML圖形進行拆解，將UML圖形拆解后的結果存儲到數據庫MgtDB中。
[0092]其中，拆解策略可以是:對于UML用例圖:重復的使用者看作同一用戶，計數為I ;相同的用例依然看作不同用例，計數為N ;3級擴展用例可忽略，計數為O ;對于UML時序圖:重復的對象看作同一對象，計數為I ;同一對象自身的調用消息可忽略，計數為O ;2個對象間相同的調用消息看作不同消息，計數為N ;對于UML類圖:重復的類看作同一個類，計數為I;同一類中名字相同的方法看作同一方法，計數為I;不同類中名字相同的方法看作不同的方法，計數為N。這里僅僅是對拆解策略進行舉例說明，并不用于限定拆解策略，拆解策略可根據項目實際需求設置。
[0093]步驟202:根據預先設置的UML模型復雜度判定策略及拆解結果，估算UML模型復雜度。
[0094]根據預先設置的UML模型復雜度判定策略及拆解結果，按照以下公式計算各階段UML模型復雜度。其中，假設UML模型復雜度判定策略如表1所示。
【權利要求】
1.一種基于統(tǒng)一建模語言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用例圖；系統(tǒng)設計階段的UML時序圖；編碼階段的UML類圖。
5.根據權利要求4所述的量化項目資源控制方法，其特征在于，所述估算UML模型復雜度包括: 所述需求階段的ULM用例圖的復雜度CPfw由用例個數和用戶角色個數決定； 所述系統(tǒng)設計階段的UML時序圖的復雜度CPsit由對象個數和對象間的交互次數決定; 所述編碼階段的UML類圖的復雜度CP由類的個數和所有類的方法個數決定。
6.根據權利要求1或2或3所述的量化項目資源控制方法，其特征在于，所述建立軟件過程中各階段的過程性能基線PPB與模型PPM包括: 對所述識別出的子影響因子進行組合得到組合影響因子，確定子過程指標與組合影響因子的相關性； 判定具有相關性的子過程指標與組合影響因子的過程數據穩(wěn)定后，對穩(wěn)定的過程數據中的子過程指標與子影響因子進行正態(tài)校驗； 對滿足正態(tài)分布的子過程指標與組合影響因子進行回歸分析以建立PPB與PPM。
7.根據權利要求6所述的量化項目資源控制方法，其特征在于，所述確定子過程指標與組合影響因子的相關性包括: 使用散點圖判斷所述子過程指標與組合影響因子的相關性，若相關系數r大于預先設置的相關性閾值，則具有相關性。
8.根據權利要求6所述的量化項目資源控制方法，其特征在于，所述判定具有相關性的子過程指標與組合影響因子的過程數據穩(wěn)定包括: 使用控制圖繪制所述子過程指標與組合影響因子的過程能力趨勢，并按照預先設置的穩(wěn)定策略判斷其過程數據是否穩(wěn)定。
9.根據權利要求6所述的量化項目資源控制方法，其特征在于，所述滿足正態(tài)分布為滿足正態(tài)分布且無分組。
10.根據權利要求9所述的量化項目資源控制方法，其特征在于，如果不滿足正態(tài)分布，該方法還包括: 使用方差分析判斷項目收集的數據是否具有明顯分組性，如果具有明顯分組行，則對不同組別的數據進行回歸分析； 如果不具有分組特性，則返回所述根據歷史項目數據識別出用于UML建模的影響因子，重新收集項目的數據。
【文檔編號】G06Q50/00GK103577882SQ201310567232
【公開日】2014年2月12日 申請日期:2013年11月14日 優(yōu)先權日:2013年11月14日
【發(fā)明者】王春佳, 季文翀, 何志強 申請人:中國聯(lián)合網絡通信集團有限公司, 聯(lián)通系統(tǒng)集成有限公司