李 引，劉東成，袁 峰，魏 革，陽 昕

1.廣州中國科學(xué)院 軟件應(yīng)用技術(shù)研究所，廣州 511458 2.廣東金賦信息科技有限公司，廣東 佛山 528200

◎工程與應(yīng)用◎

軟件研發(fā)中的精細(xì)化人力資源管理模型及系統(tǒng)

李 引1，劉東成1，袁 峰1，魏 革2，陽 昕1

1.廣州中國科學(xué)院 軟件應(yīng)用技術(shù)研究所，廣州 511458 2.廣東金賦信息科技有限公司，廣東 佛山 528200

軟件項目研發(fā)的成功與否，人力資源的管理起著決定性作用。從實踐項目中提出了精細(xì)化人力資源管理的模型，將人力資源、軟件項目、任務(wù)等抽象成具有狀態(tài)、屬性和操作的實體，通過定義任務(wù)效率、效率奇點等指標(biāo)，綜合SPI、CPI指標(biāo)進(jìn)行項目成本進(jìn)度偏差分析，為人力資源的計劃、調(diào)度、沖突處理等提供支撐。基于該模型進(jìn)行平臺研發(fā)，并通過在該平臺中跟蹤和分析真實的精細(xì)化人力資源管理案例，驗證了模型的有效性。

精細(xì)化；項目管理；人力資源管理

1 引言

針對軟件過程、軟件項目管理，國際上提出了PACE（Product And Cycle-time Excellence）[1]、ISO9000 質(zhì)量管理體系[2]、CMM/CMMI[3-5]、項目管理知識體系（PMBOK）[6]、敏捷開發(fā)（Scrum[7-8]等）、RUP[9]等一系列的管理模型和體系，它們從不同的角度對項目管理的過程、產(chǎn)出、角色等要素進(jìn)行了建模，具有各自的適用性。軟件研發(fā)是復(fù)雜的智力活動，人力資源的安排、使用與管理將對項目的成敗起著決定性的作用。在對上述模型體系分析研究的基礎(chǔ)上，針對人力資源的管理，研究了如何對人力資源進(jìn)行精細(xì)化管理的問題。精細(xì)化管理的核心在于通過對數(shù)據(jù)的分析，找出問題所在，并制定詳細(xì)可行的控制措施。隨著信息化技術(shù)的發(fā)展，人力資源管理軟件逐漸被廣泛采用，也為精細(xì)化管理提供了可能。精細(xì)化人力資源管理是一個全面化的管理模式，是一個與項目管理緊密相關(guān)的應(yīng)用領(lǐng)域[10-12]。

基于以上分析，研究的問題主要包括：（1）對精細(xì)化人力資源管理領(lǐng)域建模。為了實現(xiàn)精細(xì)化人力資源管理，對人力資源也進(jìn)行了建模。人力資源作為對象，擁有資源計劃、工作時間等重要屬性，與項目管理緊密相連，并通過報工日志形成項目管理與人力資源管理的閉環(huán)。（2）如何統(tǒng)計與分析模型產(chǎn)生的數(shù)據(jù)。對于精細(xì)化人力資源管理模型中產(chǎn)生的大量基礎(chǔ)數(shù)據(jù)，如何進(jìn)行收集和有效的數(shù)據(jù)分析，從而對項目管理起到評估和監(jiān)控作用，對此進(jìn)行了研究和分析。（3）如何將模型更好地服務(wù)于面向?qū)ο蟮男枨蠓治鲞^程。對于當(dāng)前面向?qū)ο蟮男枨蠓治鼋Y(jié)果難以復(fù)用的問題，對此進(jìn)行了討論，并提出了一種需求分析方法。

第2章對業(yè)務(wù)邏輯進(jìn)行了分析，對人力管理領(lǐng)域進(jìn)行建模，引入度量指標(biāo)對模型中產(chǎn)生的基礎(chǔ)數(shù)據(jù)進(jìn)行分析。基于該模型，在第3章介紹了系統(tǒng)的實現(xiàn)。在第4章說明了真實項目如何運(yùn)用模型進(jìn)行管理和調(diào)整，并起到監(jiān)控效果。最后進(jìn)行總結(jié)。

2 精細(xì)化人力資源管理模型

2.1 業(yè)務(wù)邏輯分析

采用領(lǐng)域驅(qū)動設(shè)計的方式，對軟件研發(fā)中的各個活動、過程、產(chǎn)出等進(jìn)行分析建模[13]，以人力資源管理為中心的軟件研發(fā)過程涉及的業(yè)務(wù)邏輯如圖1所示。

立項時需指定項目負(fù)責(zé)人，設(shè)定項目目標(biāo)、項目周期等關(guān)鍵要素，項目負(fù)責(zé)人對該項目具有最大權(quán)限，可查看所有項目成員的報工日志，查看項目進(jìn)度，對項目進(jìn)行資源分配，創(chuàng)建及變更計劃等操作。立項完成后，該項目進(jìn)入項目列表中，處于已啟動狀態(tài)。

處于已啟動狀態(tài)的項目，項目負(fù)責(zé)人可以對其進(jìn)行項目計劃。由于實際工程的需要，項目負(fù)責(zé)人可以為一個項目創(chuàng)建多個（草擬）項目計劃。這些項目計劃在正式發(fā)布前，均處于草稿狀態(tài)，項目負(fù)責(zé)人可以據(jù)此與團(tuán)隊成員進(jìn)行溝通。最終，項目負(fù)責(zé)人將發(fā)布一個正式的項目計劃，即每個項目只能有一個生效的項目計劃。

項目負(fù)責(zé)人可以對已生效的項目計劃進(jìn)行任務(wù)拆分。任務(wù)拆分遵循WBS規(guī)則，即以最小可交付成果為原則進(jìn)行拆分。底層任務(wù)即工作包，并通過底層任務(wù)將項目管理與資源管理有效銜接。

底層任務(wù)由于是以可交付成果為單位，因此底層任務(wù)與資源并非一一對應(yīng)。項目負(fù)責(zé)人需將底層任務(wù)再拆分到每一個資源，即拆分成與資源一一對應(yīng)的簡單任務(wù)，并指派到該資源。簡單任務(wù)并不是項目管理宏觀監(jiān)控的關(guān)注點，卻是項目進(jìn)度、成本、資源使用情況等的基礎(chǔ)數(shù)據(jù)來源。

項目進(jìn)行時，項目成員通過查看自己每天的簡單任務(wù)列表，對自己當(dāng)天的工作進(jìn)行安排，并需要填寫報工（每個簡單任務(wù)的投入時間、進(jìn)度、完成情況等），從而形成項目“計劃——執(zhí)行——監(jiān)控”的PDCA[14]閉環(huán)控制。報工日志中的數(shù)據(jù)將匯總到項目管理和資源管理中，對項目總體進(jìn)度以及資源使用情況產(chǎn)生影響。

項目立項完成后，項目負(fù)責(zé)人可對該項目進(jìn)行資源分配。資源分配依次需經(jīng)過創(chuàng)建資源計劃、資源沖突檢測及確認(rèn)三個步驟。創(chuàng)建資源計劃是以項目為單位，申請將某資源在某段時間內(nèi)。資源計劃創(chuàng)建完成后，系統(tǒng)將自動進(jìn)行資源沖突檢測，將該資源在計劃時間段內(nèi)是否發(fā)生沖突以及工作飽和度返回給項目負(fù)責(zé)人，若發(fā)生沖突，則項目負(fù)責(zé)人必須對資源計劃進(jìn)行修改。確認(rèn)后，則該資源將在計劃時間段內(nèi)屬于該項目的資源池中，項目負(fù)責(zé)人進(jìn)行任務(wù)拆分和指派時，可從項目的資源池中進(jìn)行分配。

當(dāng)項目的所有任務(wù)都已完成時，項目負(fù)責(zé)人可發(fā)起結(jié)項申請。項目聯(lián)系人或客戶根據(jù)立項時設(shè)定的項目目標(biāo)，對項目成果進(jìn)行驗收。驗收通過后，該項目完成結(jié)項，項目管理階段到此結(jié)束，所有資源將被釋放，項目信息不得再進(jìn)行修改。

2.2 項目管理領(lǐng)域建模

項目是模型的管理單位，項目概念的建立從項目立項開始。項目應(yīng)當(dāng)包含項目計劃、項目周期、項目成本等基本要素，此外還包含項目描述信息、項目狀態(tài)及監(jiān)控參數(shù)。

定義1 項目（Project）

Project=〈{projectStates}，{name，info，plan，planned-TimeCycle，cost，monitoringParameters}，{InitProject，New-Plan，DisHumanResource，CloseProject}＞。其中，項目狀態(tài)projectStates，在定義2項目狀態(tài)（ProjectStates）中進(jìn)行說明。

name：項目名稱，可唯一標(biāo)識項目。

info：項目基本信息，包括項目描述、項目目標(biāo)、項目總監(jiān)、項目經(jīng)理等必要的說明。

圖 1 業(yè)務(wù)邏輯圖

plan：定義 4中的項目計劃，每個項目可包含多個計劃，但只有一個生效計劃。

plannedTimeCycle：計劃項目周期，該時間不會隨著項目計劃的變更而改變。

cost：當(dāng)前已花費的項目成本，包括人力成本及其他費用。

monitoringParameters：項目監(jiān)控參數(shù)。掙值分析是測量工作績效的常用分析方法，進(jìn)度執(zhí)行指數(shù)（SPI）和成本執(zhí)行指數(shù)（CPI）是用來監(jiān)控項目成本和進(jìn)度的有效方法。除了用來反映項目狀態(tài)，更是通過狀態(tài)的分析來做出相應(yīng)的應(yīng)對措施來解決實際問題，從而使CPI和SPI的數(shù)據(jù)趨于正常。在本模型中，引入CPI及SPI作為項目監(jiān)控的參數(shù)，具體內(nèi)容在定義21項目監(jiān)控參數(shù)中進(jìn)行說明。

定義2項目狀態(tài)（ProjectStates）

ProjectStates=（INITIALIZED，RUNNING，PAUSE，CLOSING，CLOSED）。

分別為已啟動、進(jìn)行中、暫停、結(jié)項中、已結(jié)項，轉(zhuǎn)換關(guān)系如圖2所示。

已啟動：項目立項之后，項目狀態(tài)變?yōu)橐褑?，本模型對項目的管理從已啟動的項目開始。

進(jìn)行中：當(dāng)項目計劃生效之后，項目變?yōu)檫M(jìn)行狀態(tài)，在進(jìn)行狀態(tài)的項目可以進(jìn)行報工、資源申請與分配等操作。

暫停：當(dāng)遇到某些情況，需要將項目暫停時，可將項目設(shè)置為暫停狀態(tài)。暫停狀態(tài)下，成本不再增加，但計劃不順延。即項目暫停不影響成本，但影響進(jìn)度。

結(jié)項中：項目中所有任務(wù)均完成的時候，可以提交結(jié)項申請。

已結(jié)項：結(jié)項申請確認(rèn)通過時，項目變?yōu)橐呀Y(jié)項狀態(tài)，對該項目的管理到此結(jié)束。

項目管理從立項操作開始。下面對項目立項操作進(jìn)行定義。

定義3項目立項（InitProject）

InitProject=〈{project}，{NULL}，{project.states=INITIALIZED}＞。立項之后，才建立項目的概念，才能對其進(jìn)行后續(xù)操作。立項操作完成后，項目狀態(tài)變?yōu)橐褑?，可以對項目制定項目計劃、分配資源等。立項時需要確定項目的一些關(guān)鍵信息。下面對項目計劃對象進(jìn)行定義。

定義4項目計劃（Plan）

一個項目有許多的項目計劃活動，每個計劃活動都有著計劃名稱、計劃版本、計劃時間周期，以及一系列的任務(wù)集合。任務(wù)集合是每個計劃活動進(jìn)一步細(xì)化的成果。每個任務(wù)都包含有任務(wù)名，任務(wù)時間周期，人力資源集合，計劃工作量，實際工作量，已投入工作量。其中已投入工作量是指任務(wù)中每個人力資源的已投入工作量與任務(wù)已開始時間的乘積的和。

Plan=〈{isEffect}，{name，type，version，cycle，task-Set}，{NewPlan，ModPlan}＞。

狀態(tài)isEffect=（TRUE，F(xiàn)ALSE），計劃生效時isEffect=TRUE，反之則為FALSE。

name：項目計劃的名稱。

type：項目計劃表的類型，如 type=（Gant，Burn-DownChart），甘特圖或燃盡圖。

version：項目計劃的版本號。

cycle：當(dāng)前計劃項目周期，調(diào)整計劃時，該時間可能會發(fā)生改變。

對項目計劃的主要操作有制定項目計劃以及調(diào)整項目計劃。制定項目計劃一般在項目立項之后，而調(diào)整項目計劃往往發(fā)生在正在進(jìn)行的項目中。下面對這兩個操作進(jìn)行定義。

定義5制定項目計劃（NewPlan）

NewPlan=〈{project，plan}，{project.states=INITIALIZED}，{plan.isEffect=TRUE，project.states=RUNNING}＞。只能對已初始化的項目制定項目計劃，每個項目可包含多個項目計劃，但只能有一個生效計劃。計劃生效之后，才能進(jìn)行細(xì)化。此階段不涉及資源的分配，與資源的關(guān)聯(lián)將在對計劃的細(xì)化中進(jìn)行。項目進(jìn)行中，可以對生效計劃進(jìn)行調(diào)整。

定義6調(diào)整項目計劃（ModPlan）

圖2 項目狀態(tài)轉(zhuǎn)換圖

ModPlan=〈{oldPlan，newPlan}，{oldPlan.isEffect=TRUE}，{oldPlan.isEffect=FALSE，newPlan.isEffect=TRUE}＞。此操作指的是在在項目進(jìn)行中對已生效的計劃進(jìn)行調(diào)整，因此前置條件為oldPlan.isEffect=TRUE。操作完成后，舊計劃失效，新計劃生效。

本模型采用工作分解結(jié)構(gòu)（Work Breakdown Structure，WBS），以可交付成果為導(dǎo)向?qū)椖恳剡M(jìn)行分組。WBS最低層次的項目可交付成果稱為工作包，對應(yīng)模型中的任務(wù)。每個任務(wù)可以有多個項目成員參與執(zhí)行。因此需要對任務(wù)對象進(jìn)行建模，定義如下。

定義7任務(wù)（Task）

Task=〈{isFinished}，{name，fatherTask，belongToPlan，plannedTimeCycle，actualTimeCycle，humanResourceSet，plannedWorkload，acturalWorkload，simpleTaskSet}，{NULL}＞。

其中，狀態(tài)isFinished={TRUE，F(xiàn)ALSE}任務(wù)是否完成，完成時isFinished=TRUE，此時該任務(wù)下的所有簡單任務(wù)均已完成，且不得再進(jìn)行報工，未完成時isFinished=FALSE。

name：任務(wù)名，可以對任務(wù)進(jìn)行唯一標(biāo)識。

fatherTask：父任務(wù)。

belongToPlan：所屬項目計劃。

plannedTimeCycle：任務(wù)計劃周期。

actualTimeCycle：任務(wù)實際執(zhí)行周期。

humanResourceSet：表示一切參與到該任務(wù)的人力資源的集合，也就是定義6中的人力資源。

plannedWorkload：任務(wù)計劃工作量。

actualWorkload：任務(wù)實際工作量。

simpleTaskSet：簡單任務(wù)（定義8）集合，simpleTask-，其中n表示該項目任務(wù)中簡單任務(wù)的數(shù)量。

由于任務(wù)是以可交付成果為導(dǎo)向，一個任務(wù)可對應(yīng)多個資源，無法收集單個資源在單個任務(wù)中的執(zhí)行情況，于是引入簡單任務(wù)概念。表示為：

定義8簡單任務(wù)（SimpleTask）

SimpleTask=〈{NULL}，{belongToTask，plannedWorkload，acturalWorkload，humanResource}，{DisHumanResource，Report}＞。

belongToTask：所屬任務(wù)，一個簡單任務(wù)只能所屬一個任務(wù)。

plannedWorkload：簡單任務(wù)的計劃工作量。

actualWorkload：簡單任務(wù)的實際工作量。

humanResource：簡單任務(wù)對應(yīng)的資源，定義16中定義的資源。

簡單任務(wù)不可再分，不可獨立于所屬任務(wù)存在，每個簡單任務(wù)對應(yīng)一個資源。任務(wù)、簡單任務(wù)、資源的關(guān)系如圖3所示。與簡單任務(wù)相關(guān)的操作有報工（定義11）及資源分配（定義18）。

圖3 簡單任務(wù)示意圖

項目運(yùn)行情況的收集是通過資源填寫報工日志完成。資源根據(jù)簡單任務(wù)列表提交當(dāng)日的報工日志，將各簡單任務(wù)的完成情況匯總成任務(wù)完成情況，從而對項目的整體進(jìn)度產(chǎn)生影響。項目負(fù)責(zé)人可以查看項目進(jìn)度與計劃，并對項目計劃作出調(diào)整。下面對報工日志以及報工操作進(jìn)行定義：

定義9報工日志（WorkLog）

WorkLog=〈{EFFECT，DRAFT}，{humanResource，simpleTask，workload，accomplishRate}，{NewWorkLog，Report}＞。

humanResource：定義16中的人力資源。

simpleTask：定義8中的簡單任務(wù)。

workLoad：當(dāng)天工作量。

accomplishRate：任務(wù)完成度。

定義10 報工（Report）

Report=〈{workLog，simpleTask}，{simpleTask.human-Resource=worklog.humanResource}，{worklog.states=EFFECT}＞。

其中，前置條件為報工日志中的資源與簡單任務(wù)中的資源對應(yīng)。報工日志提交后，對應(yīng)的簡單任務(wù)的實際工作量將更新為加上本次日志中工作量的總和。報工是模型中的重要操作，將計劃與實際有效聯(lián)系起來。資源根據(jù)計劃（定義4）中的簡單任務(wù)（定義8），填寫實際工作量以及任務(wù)完成情況，收集該數(shù)據(jù)可進(jìn)行任務(wù)完成情況、項目運(yùn)行情況、資源效率等分析。完成報工操作后，該報工日志生效，即狀態(tài)變?yōu)镋FFECT。

項目計劃中所有任務(wù)均完成后，可提交結(jié)項報告（對象），進(jìn)行項目結(jié)項操作。每個項目只允許提交一份結(jié)項報告。

定義11結(jié)項報告（ProjectCloseReport）

ProjectCloseReport=〈{PENDING，EFFECT，F(xiàn)AIL}，{projectName，plannedTimeCycle，actualTimeCycle，acceptanceList，qualityEvalution}，{CloseProject}＞。

提交結(jié)項報告后，該報告正在處理中，Project-CloseReport.states=PENDING；報告生效后，Project-CloseReport.states=EFFECT；結(jié)項不通過，則Project-CloseReport.states=FAIL。當(dāng)且僅當(dāng)一個項目的結(jié)項報告處于FAIL狀態(tài)時，可重新提交一份結(jié)項報告。

projectName：項目名稱。

plannedTimeCycle：計劃項目周期，對應(yīng)定義 1項目中的值。

actualTimeCycle：項目實際運(yùn)行周期。

acceptanceList：驗收清單。

qualityEvaluaion：質(zhì)量評價。

定義12項目結(jié)項（CloseProject）

CloseProject=〈{project，ProjectCloseReport}，{?i∈（1，n），taski.isFished=TRUE，n為項目中任務(wù)總數(shù)}，{NewCloseReport，ConfirmClose}，{ProjectCloseReport.states=EFFECTamp;project.states=CLOSED or ProjectCloseReport.states=FAILamp;project.states=CLOSING}＞。項目結(jié)項為復(fù)雜操作，包括新建結(jié)項報告和確認(rèn)結(jié)項兩個基本操作，具體定義如下：

定義13新建結(jié)項報告（NewCloseReport）

NewCloseReport=〈{project，ProjectCloseReport}，{?i∈（1，n），taski.isFished=TRUE，n為項目中任務(wù)總數(shù)}，{ProjectCloseReport.states=PENDING，project.states=CLOSING}＞。僅當(dāng)項目中所有任務(wù)的狀態(tài)均為已完成（taski.isFished=TURE），項目才能提交結(jié)項報告。

定義14確認(rèn)結(jié)項（ConfirmClose）

ConfirmClose=〈{project，ProjectCloseReport}，{Project-CloseReport.states=PENDING，project.states=CLOSING}，{ProjectCloseReport.states=EFFECTamp;project.states=CLOSED or ProjectCloseReport.states=FAILamp;project.states=CLOSING}＞。

提交結(jié)項報告后，報告的狀態(tài)變?yōu)镻ENDING，項目狀態(tài)變?yōu)镃LOSING。此時由決策者根據(jù)報告中的內(nèi)容進(jìn)行評價，最終對是否結(jié)項進(jìn)行確認(rèn)。確認(rèn)結(jié)項后，結(jié)項報告生效，ProjectCloseReport.states=EFFECT，且項目狀態(tài)變?yōu)镃LOSED。若決策者認(rèn)為該結(jié)項報告不符合要求，不予結(jié)項，則將報告狀態(tài)置為FAIL，項目處于CLOSING狀態(tài)，此時可為該項目重新創(chuàng)建一份結(jié)項報告。處于已結(jié)項狀態(tài)的項目，不能再進(jìn)行計劃變更或報工等操作。項目結(jié)項后，對該項目的管理工作全部完成。

2.3 人力資源管理領(lǐng)域建模

人力資源是復(fù)雜的，它包含有一系列的專業(yè)知識和技能屬性，以及與它有所關(guān)聯(lián)的其他資源屬性。它包含有一系列的屬性，實際上，在項目管理過程中，項目是多變的，人力資源本身也是多變的。人的專業(yè)知識和行為能力與他所具備的項目管理經(jīng)驗，參與項目實踐時間，學(xué)習(xí)能力都是相關(guān)的。一個參與過類似項目，參與此次項目時間長久，學(xué)習(xí)效率高的人會更為高效地完成項目規(guī)定計劃。這種行為活動是一種自學(xué)習(xí)，自適應(yīng)的項目計劃活動。人力資源是一種瞬時資源，在項目計劃階段做好的資源計劃趕不上資源變化，人力資源在項目活動中實際執(zhí)行的行為時間是不確定的。因為隨時可能由于計劃變更，需求變更或者有優(yōu)先級別更高的項目進(jìn)入影響到當(dāng)前項目計劃，此時資源可采取滿負(fù)荷加班方式完成額外的項目需求，也可以通過采取與企業(yè)管理層協(xié)商決定先投入哪個項目達(dá)成共識的方式來完成自身的計劃進(jìn)度安排。

針對人力資源的復(fù)雜性、多變性、不確定性，把人作為項目過程管理中的基本元素進(jìn)行資源定義。

定義15人力資源（HumanResource）

HumanResource=〈{NULL}，{name，planSet，availible-Time，scheduledTime，skillSet，workingTime，fullTime，efficiency}，{DisHumanResource，Report}＞

name：人力資源的名稱，可唯一標(biāo)識人力資源。

planSet：定義16中的資源計劃的集合，一個資源可包含多個資源計劃。

availibleTime：人力資源的可用時間。

scheduledTime：人力資源的已安排時間。

skillSet：人力資源的技能集合，其中每個技能Skill被定義為一個三元組〈SkillName，SkillType，SkillLevel＞，每個人力資源所擁有的技能是所有他所擁有的技能名稱、技能類型以及掌握程度的集合。

workingTime：人力資源的已工作時間。

fullTime：資源每天的滿荷工作時間，可按不同需要進(jìn)行設(shè)定，一般fullTime=8.0 h。

efficiency：資源效率，資源投入的所有任務(wù)的任務(wù)完成效率平均值，計算公式：

定義16資源計劃（HumanResourcePlan）

資源計劃是一個資源在某段時間內(nèi)的工作安排情況，表示該資源在某時間段內(nèi)對某項目的參與度。一個資源可包含多個資源計劃。

HumanResourcePlan=〈{PENDING，EFFECT，F(xiàn)AIL}，{timeSpam，projectName，participation}，{DisHumanResource}＞。

提交資源申請后，相應(yīng)的資源計劃的狀態(tài)變?yōu)镻ENDING；成功分配后，狀態(tài)變?yōu)镋FFECT；申請失敗，則狀態(tài)為FAIL。

timeSpam：該資源計劃的時間段。

projectName：所參與的項目。

participation：參與度，含義為資源投入該項目的工作量，占自身所有工作量的比例，用百分比表示。

例如，資源小王2015年1月1日至2月1日參與項目A，參與度為70%，此為資源計劃1。同時，小王2015年1月5日至2月15日參與項目B，參與度為40%，此為資源計劃2。

定義17資源分配（DisHumanResource）

資源分配操作指的是為某項目創(chuàng)建一系列資源計劃，并確認(rèn)是否生效的過程。操作序列為復(fù)雜操作，包括創(chuàng)建資源計劃（定義18）、資源沖突檢測（定義19）以及確認(rèn)操作（定義20）。定義如下：

DisHumanResource=〈{project，humanResource，humanResourcePlan}，{project.states=Initiated or project.states=RUNNING}，{NewHumanResourcePlan，Detect-Conflict，ConfirmDis}，{humanResourcePlan.states=EFFECT or humanResourcePlan.states=FAIL}＞。

定義18創(chuàng)建資源計劃（NewHumanResourcePlan）

NewHumanResourcePlan=〈{project，humanResource，humanResourcePlan}，{project.states=Initiated or project.states=RUNNING}，{humanResourcePlan.states=PENDING}＞

定義19資源沖突檢測（DetectConflict）

先定義幾個術(shù)語：

資源飽和率（saturationRate）：資源分配時在某時間段內(nèi)其資源占用率的大小。它描述了資源的沖突強(qiáng)度。正常使用資源的飽和率上限，成為飽和率閥值（saturationThreshold），可根據(jù)需要設(shè)定。

資源沖突（confliction）：資源在某個時間段內(nèi)，其資源飽和率超過閥值，則稱該資源在該時間段內(nèi)發(fā)生了資源沖突。

DetectConflict=〈{humanResource，humanResourcePlan}，{humanResource Plan.states=PENDING}，{isConflict=TRUE or isConflict=FALSE，saturationRate=rate}＞。資源沖突檢測的前置條件是提交了資源計劃申請，即humanResourcePlan.states=PENDING。計算飽和率的方法為將資源計劃中的資源使用時間，加上資源當(dāng)前的已安排時間，即計算假設(shè)該資源按照此資源計劃進(jìn)行工作的飽和率。資源沖突檢測的結(jié)果為是否發(fā)生沖突，及該資源的飽和率。該結(jié)果將影響操作者的決策。

定義20確認(rèn)分配（ConfirmDis）

ConfirmDis=〈{project，humanResource，humanResourcePlan}，{isConflict=TRUE or isConflict=FALSE，saturationRate=rate}，{humanResourcePlan.states=EFFECT or humanResourcePlan.states=FAIL}＞

資源沖突檢測的結(jié)果為是否發(fā)生沖突，及該資源的飽和率。模型本身并不進(jìn)行決策，需要操作者進(jìn)行結(jié)果確認(rèn)，即Confirm。操作的結(jié)果可以是該資源計劃生效（humanResourcePlan.states=EFFECT）或放棄該資源計劃（humanResourcePlan.states=FAIL）。

2.4 度量指標(biāo)建模

針對項目執(zhí)行進(jìn)度和成本，一般采用經(jīng)典的CPI和SPI進(jìn)行，如下定義。

定義21項目監(jiān)控參數(shù)

用二元組〈parameter，value＞表示，MonitoringParameters={〈paragrameter1，value1＞，〈paragrameter2，value2＞}。

parameter：參數(shù)類型，在本模型中采用SPI和CPI。

value：參數(shù)范圍，value={H，N，L}，H為運(yùn)行良好下限，N為運(yùn)行正常下限，L為輕微偏差下限。監(jiān)控參數(shù)值value≥H時，運(yùn)行良好；H＞value≥N時，運(yùn)行正常；N＞value≥L時，輕微偏差；value＜L時，嚴(yán)重偏差。

計算公式：

其中，PV為在規(guī)定的時間內(nèi)在工作上將要花費的獲得批準(zhǔn)的成本估算部分，AC為在規(guī)定時間內(nèi)完成工作所花費的實際成本，EV為實際完成工作的價值。項目中所有任務(wù)的指數(shù)平均值為項目指數(shù)。

由任務(wù)（定義7任務(wù)（Task））及簡單任務(wù)（定義8簡單任務(wù)（SimpleTask）的定義可知，項目管理模型中一份項目計劃包含有多個任務(wù)，每個任務(wù)又可以分配多個人力資源，任務(wù)與人力資源是一對多的關(guān)系，而簡單任務(wù)是不可再分的任務(wù)，每個簡單任務(wù)對應(yīng)一個人力資源。人力資源與項目之間的銜接可以通過報工日志，項目變更，資源申請，資源分配等方式。其中在報工日志中，人力資源通過簡單任務(wù)與項目計劃進(jìn)行交互。簡單任務(wù)執(zhí)行效率只表示該資源在該任務(wù)中的執(zhí)行情況，但是統(tǒng)計某個資源的所有簡單任務(wù)的完成效率，可反映該資源的執(zhí)行效率。因此，在這里引入兩個統(tǒng)計量：

定義22簡單任務(wù)完成效率（TaskEfficiency）

其中p為任務(wù)完成度，用百分比表示。以每人每任務(wù)為計算單位，表示該資源在該任務(wù)上的完成效率。PVt為簡單任務(wù)的計劃完成時間，ACt為簡單任務(wù)的實際工作時間。當(dāng)實際完成效率與計劃預(yù)期一致時，TaskEfficiency=1；當(dāng)實際完成效率低于預(yù)期時，TaskEfficiency＜1；反之，TaskEfficiency＞1。

例如，某簡單任務(wù)的計劃完成時間是10 h（PVt=10 h），當(dāng)前已工作5 h（ ACt=5 h），當(dāng)前該簡單任務(wù)的完成度為40%，則

說明該簡單任務(wù)的完成效率低于預(yù)期。

該值與進(jìn)度成本指數(shù)SPI、CPI的計算方法類似，與之不同的是，沒有將資源成本計入公式，僅計算任務(wù)完成度與預(yù)期的關(guān)系，直觀地反映了該資源在該簡單任務(wù)上的完成效率，或者該任務(wù)工時預(yù)估的準(zhǔn)確度。

定義23效率奇點（SingularPoint）

當(dāng)TaskEfficiency＞H或TaskEfficiency＜L時，該簡單任務(wù)稱為效率奇點簡單任務(wù)（SingularPoint）。L、H為正常值的上下限，根據(jù)經(jīng)驗數(shù)據(jù)計算得出。一般的，L=0.9，H=1.2。

項目的SPI、CPI出現(xiàn)偏差時，可參照對項目奇點率的統(tǒng)計進(jìn)行分析，若奇點率高，則說明很多任務(wù)都出現(xiàn)了進(jìn)度偏差，考慮是計劃問題；若奇點率低，說明出現(xiàn)偏差的任務(wù)少，但偏差嚴(yán)重，則考慮是資源執(zhí)行力的問題。人力資源的變動有可能造成項目計劃的變動，同時，項目計劃的改動也會造成人力資源的變更。通過采用這種模型機(jī)制，能夠?qū)㈨椖窟^程中的每個階段精確到每個人力資源的控制中去，生成可信可用的調(diào)度計劃，及時反應(yīng)人力資源的最新狀態(tài)，項目的最新執(zhí)行進(jìn)度等。

該精細(xì)化人力資源管理模型適用于傳統(tǒng)開發(fā)模式以及迭代開發(fā)模式。資源在每個項目任務(wù)中的報工都會及時反饋到資源的基礎(chǔ)數(shù)據(jù)以及項目進(jìn)度中，項目計劃與進(jìn)度的展現(xiàn)方式可根據(jù)不同的開發(fā)模式選擇為甘特圖或燃盡圖。對于傳統(tǒng)開發(fā)模式，項目立項后進(jìn)行項目計劃、分配資源，在項目進(jìn)行中，通過成本分析、進(jìn)度分析以及資源效率分析，對項目計劃進(jìn)行調(diào)整。對于迭代開發(fā)模式，項目啟動后，每個迭代周期進(jìn)行項目計劃、分配資源、項目監(jiān)控過程，通過模型對參數(shù)的統(tǒng)計與分析，指導(dǎo)下一迭代周期的計劃與資源分配。

對項目進(jìn)行監(jiān)控時，需要結(jié)合項目監(jiān)控參數(shù)CPI和SPI，以及任務(wù)奇點率進(jìn)行分析。由于大于或小于正常效率范圍的點均為效率奇點任務(wù)，所以任務(wù)奇點率高有兩種情況，即簡單任務(wù)完成效率偏低或偏高。

下面分別對這四種情況進(jìn)行分析：

（1）若項目監(jiān)控參數(shù)（CPI、SPI）指數(shù)較高，任務(wù)奇點率較高，說明項目計劃安排不合理。若項目中的簡單任務(wù)完成效率普遍高出正常值，則說明任務(wù)的工作量估計不準(zhǔn)確，導(dǎo)致資源普遍過于超前完成任務(wù)；若項目中的簡單任務(wù)完成效率普遍偏低，則說明資源的分配不合理，即掙得值大的任務(wù)完成情況良好，而掙得值小的任務(wù)進(jìn)度延后。

（2）若項目監(jiān)控參數(shù)（CPI、SPI）指數(shù)較低，任務(wù)奇點率較高，說明項目計劃安排不合理。若項目中的簡單任務(wù)完成效率普遍高出正常值，則說明任務(wù)拆分不合理，導(dǎo)致掙得值大的任務(wù)進(jìn)度延后，或資源出現(xiàn)問題（工作效率低于正常值）；若項目中的簡單任務(wù)完成效率普遍偏低，則說明任務(wù)拆分不合理，對任務(wù)的工作量估計不準(zhǔn)確，資源普遍無法按計劃完成任務(wù)。

（3）若項目監(jiān)控參數(shù)（CPI、SPI）指數(shù)較高，任務(wù)奇點率較低，說明項目運(yùn)行狀態(tài)正常。

（4）若項目監(jiān)控參數(shù)（CPI、SPI）指數(shù)較低，任務(wù)奇點率較低，說明資源普遍按計劃完成任務(wù)進(jìn)度，但項目的掙得值和成本投入均過小，說明計劃安排不合理。

3 系統(tǒng)實現(xiàn)

本文提出的模型在廣州中國科學(xué)院軟件應(yīng)用技術(shù)研究所的在線研發(fā)管理平臺iSERP（intelligent Service of ERP）[15]中進(jìn)行了開發(fā)和實現(xiàn)。iSERP是一款面向智力服務(wù)行業(yè)的企業(yè)的項目精細(xì)化管理系統(tǒng)。它能夠為軟件、廣告、律師、金融等以人力資源智力活動為主要生產(chǎn)力的企業(yè)提供精細(xì)化的管理服務(wù)，能夠?qū)椖棵刻斓倪M(jìn)展和人力資源分布進(jìn)行監(jiān)控，為高層提供清晰明了的資源和項目視圖。

3.1 總體功能架構(gòu)

由于系統(tǒng)功能眾多，采用功能結(jié)構(gòu)圖的方式將系統(tǒng)的功能進(jìn)行分解，體現(xiàn)各個模塊間的層次關(guān)系和邏輯結(jié)構(gòu)。系統(tǒng)包括我的工作臺、資源管理、項目管理、報工管理和系統(tǒng)管理五大模塊，如圖4所示。

圖4 總體功能架構(gòu)圖

其中，項目資源成本分析、項目階段成本統(tǒng)計、項目資源使用情況分析等數(shù)據(jù)分析，均是由項目計劃及報工產(chǎn)生的基礎(chǔ)數(shù)據(jù)，根據(jù)不同企業(yè)的需求進(jìn)行的統(tǒng)計與分析。

3.2 資源管理業(yè)務(wù)流程

資源管理模塊是項目管理平臺中的基礎(chǔ)模塊之一，該模塊為其他管理提供資源基礎(chǔ)數(shù)據(jù)的來源。該模塊的主要參與者有普通員工、項目負(fù)責(zé)人及部門負(fù)責(zé)人。在系統(tǒng)中主要實現(xiàn)了資源基礎(chǔ)數(shù)據(jù)、資源申請、資源分配功能，如圖5所示。

圖5 資源管理流程

（1）資源基礎(chǔ)屬性。對資源的基礎(chǔ)數(shù)據(jù)進(jìn)行維護(hù)（請參見第3章中定義15），包括自然基礎(chǔ)數(shù)據(jù)（如名稱、技能等），以及擴(kuò)展基礎(chǔ)數(shù)據(jù)（如資源計劃、可用時間、已工作時間等）。

（2）資源申請。由項目負(fù)責(zé)人發(fā)起資源申請（即創(chuàng)建資源計劃），申請表單中需指定項目、資源、時段、參與度，表示為某個資源在某時間段內(nèi)以一定參與度投入到某項目中。由部門負(fù)責(zé)人對資源申請進(jìn)行審批。

（3）資源分配。由部門負(fù)責(zé)人對部門內(nèi)項目的資源申請進(jìn)行審批。項目負(fù)責(zé)人發(fā)起資源申請后，系統(tǒng)將進(jìn)行資源沖突檢測。當(dāng)發(fā)生了資源沖突，或資源沖突程度大于系統(tǒng)設(shè)定值時，將提醒部門負(fù)責(zé)人，部門負(fù)責(zé)人可以視情況駁回申請，再由項目負(fù)責(zé)人重新申請。當(dāng)資源申請審批通過時，系統(tǒng)將自動更新資源的信息。

（4）資源變更。在項目進(jìn)行中，項目負(fù)責(zé)人可以隨時為項目創(chuàng)建新的項目計劃，或修改已生效的資源計劃（即資源變更）。發(fā)起資源變更時，與資源申請類似，同樣需要部門負(fù)責(zé)人的審批。

3.3 實體關(guān)系

系統(tǒng)實體關(guān)系如圖6所示。項目可拆分成多個任務(wù)，每個任務(wù)可再劃分為多個簡單任務(wù)，簡單任務(wù)不能獨立于任務(wù)存在。簡單任務(wù)與人力資源一一對應(yīng)，且每天對應(yīng)一條報工日志。項目與人力資源為多對多關(guān)系，一個項目包含多個人力資源，人力資源可同時屬于多個項目。

圖6 實體關(guān)系圖

3.4 資源管理模塊詳細(xì)設(shè)計

由前文分析可知，資源屬性本身是由自然屬性和擴(kuò)展屬性復(fù)合而成，其擴(kuò)展屬性如工作屬性、技能水平等可作為一個單獨的類。資源屬性與工作屬性、技能水平之間為1..n關(guān)系，其類圖如圖7。

圖7 資源基礎(chǔ)數(shù)據(jù)類圖

資源分配操作包括創(chuàng)建資源計劃、資源沖突檢測以及確認(rèn)操作，圖8為資源沖突檢測時序圖。該操作的輸入信息為資源計劃，即在某個時間段將某資源加入某項目中，提交資源計劃時將處罰資源沖突檢測。最終返回該資源在計劃時段內(nèi)是否發(fā)生沖突以及飽和率。

圖8 資源沖突檢測時序圖

4 實例分析

下面以真實項目“桌面即時通訊工具”項目為例，對其業(yè)務(wù)場景和數(shù)據(jù)進(jìn)行分析。

4.1 項目立項

桌面即時通訊工具項目的項目周期為2015年5月1日至2016年1月31日，工作量387人天，項目計劃時分配的初始團(tuán)隊成員如表1。

表1 團(tuán)隊成員表

圖9 資源申請

圖10 資源沖突檢測

4.2 分配資源與資源變更

項目啟動后，可在創(chuàng)建項目計劃時由項目負(fù)責(zé)人申請資源（為某項目在某段時間內(nèi)申請某資源），也可先進(jìn)行資源申請，即資源申請與創(chuàng)建項目計劃沒有依賴關(guān)系。在桌面即時通訊工具項目中，項目負(fù)責(zé)人采用的是先制定頂層項目計劃，同時確定頂層任務(wù)的負(fù)責(zé)人，并為頂層任務(wù)申請資源。對于底層任務(wù)，則由所屬頂層任務(wù)的負(fù)責(zé)人，在任務(wù)開始前進(jìn)行資源申請。資源申請的界面如圖9。

項目負(fù)責(zé)人發(fā)起資源申請后，系統(tǒng)當(dāng)即會進(jìn)行資源沖突分析，根據(jù)系統(tǒng)預(yù)先設(shè)置的閾值（日工作量標(biāo)準(zhǔn)為8 h，飽和度上限為110%），當(dāng)此資源申請將使資源的工作量超出閾值時，即發(fā)生資源沖突，系統(tǒng)將給出提示。

2015年8月10日，由于發(fā)生需求變更，需要增加開發(fā)人員，于是項目經(jīng)理發(fā)起了資源變更，希望將資源王一龍加入本項目。由于王一龍同時參與了其他項目，且工作量已經(jīng)飽和，于是系統(tǒng)進(jìn)行了如圖10提示。

系統(tǒng)提示在2015年8月10日至2015年12月31日之間，王一龍發(fā)生了資源沖突，沖突率為55.4%（沖突時間/申請時間）。于是項目經(jīng)理對資源申請進(jìn)行了調(diào)整，將其他可用資源添加到了項目中，保證了項目正常進(jìn)行。

系統(tǒng)將資源沖突設(shè)置為必要條件，即所有資源申請必須通過資源沖突的檢測，才能通過，從而進(jìn)入審批流程。否則，項目負(fù)責(zé)人必須對申請進(jìn)行修改。發(fā)生沖突時，項目負(fù)責(zé)人可在所有資源列表中查看各資源的技能、可使用時間等。這種設(shè)定，保證了資源使用的合理性，實現(xiàn)資源使用情況的可視化。

4.3 報工與項目監(jiān)控

在項目計劃完成拆解，并將資源分配到簡單任務(wù)之后，對應(yīng)的資源就可以在自己的報工日志的任務(wù)列表中查看自己的任務(wù)列表，并安排當(dāng)天的工作，任務(wù)列表如圖11所示。

圖11 任務(wù)列表

任務(wù)列表中列出了當(dāng)天該資源參與的所有簡單任務(wù)（可能分屬于不同項目中），是從資源角度對簡單任務(wù)的匯總。每一項簡單任務(wù)，列出了其名稱、所屬項目/部門、任務(wù)類型、工時（總工作量）、剩余工作量（根據(jù)此前個人填寫的報工計算得出）、計劃完成時間、任務(wù)執(zhí)行情況（百分比）等，資源需根據(jù)今天工作的實際情況填寫各項任務(wù)的投入時間和完成情況。

提交后，項目負(fù)責(zé)人可查看所有成員的報工日志，且成員填寫的報工日志將及時反映在整個項目的進(jìn)度中，為項目負(fù)責(zé)人細(xì)致了解項目情況提供了基礎(chǔ)數(shù)據(jù)。

項目進(jìn)行過程中，出現(xiàn)CPI=0.78，SPI=0.71，依據(jù)系統(tǒng)中設(shè)置的值，該項目處于嚴(yán)重偏差狀態(tài)。此時，項目中所有簡單任務(wù)的完成情況如表2（未列出暫時未到計劃開始時間的任務(wù)）。

其中根據(jù)公式（4）以及前文中對效率奇點（定義26）的定義，任務(wù)效率正常值為[0.9，1.2]，因此1、6、7、9四個簡單任務(wù)效率低于正常值下限0.9，為效率奇點任務(wù)。對這四個效率奇點任務(wù)進(jìn)行分析，見表3。其中，資源效率為該資源所負(fù)責(zé)的所有簡單任務(wù)完成效率的平均值，與項目無關(guān)，反映的是該資源的工作效率。用公式（1）計算，并參見第3章中定義15。

表2 簡單任務(wù)效率表

表3 奇點任務(wù)表

可見資源本身的效率屬于正常范圍。通過與奇點任務(wù)的負(fù)責(zé)人溝通，由于開發(fā)過程中出現(xiàn)了計劃時未考慮到的技術(shù)難點，導(dǎo)致該簡單任務(wù)的完成效率較低，并重新給出了該簡單任務(wù)完成所需工時的預(yù)算。為了保證后續(xù)計劃的準(zhǔn)確性，項目經(jīng)理及時對整體計劃進(jìn)行了調(diào)整。

4.4 項目結(jié)項

當(dāng)項目計劃中的所有任務(wù)都完成時（即完成度為100%），項目負(fù)責(zé)人填寫結(jié)項報告，提交后進(jìn)入結(jié)項過程。

在本項目中，由于當(dāng)前項目計劃的完成度為92.21%，所以無法提交項目結(jié)項報告。

成功提交結(jié)項報告，進(jìn)入結(jié)項過程后，則需要由客戶對項目成果進(jìn)行驗收，系統(tǒng)自動核算實際工作量，為項目驗收提供參考數(shù)據(jù)。項目驗收通過后，即完成項目結(jié)項過程，該項目的管理活動告一段落，系統(tǒng)將自動釋放所有資源。

5 結(jié)束語

本文提出了精細(xì)化人力資源管理模型。該模型將人力資源單獨作為對象，納入到項目管理的領(lǐng)域范圍內(nèi)，而不是從屬于項目中的一部分。作為對象的人力資源，擁有資源計劃、可用工作時間、工作量等一系列屬性，在實際應(yīng)用中，可根據(jù)具體的管理需求靈活地對這些基礎(chǔ)數(shù)據(jù)進(jìn)行加工利用。項目計劃與資源之間，通過資源計劃聯(lián)系起來。首先制定整體項目計劃，再將計劃拆分為與資源一一對應(yīng)的簡單任務(wù)，由此，計劃被拆分并指派到了單個資源。而資源則通過每天的報工，對指派給其的任務(wù)完成情況進(jìn)行反饋，從而形成了項目計劃、報工、項目進(jìn)度反饋等PDCA閉環(huán)控制。

[1]PRTM.PACE[EB/OL].[2016].http：//acronyms.thefreedictionary.com/Product+and+Cycle-Time+Excellence.

[2]質(zhì)量管理體系技術(shù)委員會TC176.ISO9000[EB/OL].（1994）[2016].http：//www.iso.org/iso/home/standards/managementstandards/iso_9000.htm.

[3]Software Engineering Institute.CMM/CMMI[EB/OL].（2010）[2016]http：//www.sei.cmu.edu/cmmi/.

[4]高琰，李建華，費耀平，等.基于CMM的軟件項目管理系統(tǒng)的設(shè)計與實現(xiàn)[J].計算機(jī)工程，2002（9）：249-252.

[5]Curtis B，Hefley W E，Miller S.Overview of the people capability maturity model[J].Overview of the People Capability Maturity Model，1995.

[6] 國 際 標(biāo) 準(zhǔn) 化 組 織 ISO.PMBOK[EB/OL].（1996）[2016].http：//www.pmi.org/.

[7]Jeff S，Ken S.Scrum[EB/OL].（1991）[2016].https：//www.scrum.org/.

[8]Bougroun Z，Zeaaraoui A，Bouchentouf T.The projection of the specific practicesofthe third levelofCMMI model in agile methods：Scrum，XP and Kanban[C]//2014 Third IEEE International Colloquium in Information Science and Technology（CIST）.IEEE，2014：174-179.

[9]IBM.RUP[EB/OL].（2007）[2016].https：//en.wikipedia.org/wiki/Rational_Unified_Process.

[10]Liu S T.Project management：A systems approach to planning，scheduling and controlling（book）[J].Quality Progress，2004，37：95-96.

[11]王有偉.IT行業(yè)項目管理現(xiàn)狀及發(fā)展趨勢[J].科技創(chuàng)新導(dǎo)報，2012（17）：209-210.

[12]孫小平，方萬芽.淺談IT行業(yè)項目管理的有效方法與策略[J].硅谷，2013（1）：111-112.

[13]李引，袁峰.基于領(lǐng)域驅(qū)動設(shè)計的應(yīng)用系統(tǒng)模型[J].計算機(jī)工程與應(yīng)用，2013，49（16）：1-8.

[14]戴明.PDCA[EB/OL].（1950）[2016].https：//zh.wikipedia.org/zh/PDCA.

[15]李引，袁峰，吳鴻.基于軟件構(gòu)件技術(shù)的多租戶個性化框架[J].計算機(jī)工程與應(yīng)用，2015，51（9）：22-29.

LI Yin1,LIU Dongcheng1,YUAN Feng1,WEI Ge2,YANG Xin1

1.Institute of Software Application Technology,Guangzhouamp;Chinese Academy of Sciences,Guangzhou 511458,China 2.Guangdong KAMFU Informationamp;Technology Co.,Ltd.,Foshan,Guangdong 528200,China

Fine-grained human resource management model and system in software development.Computer Engineering and Applications,2017,53（21）：203-213.

Human resource management plays a critical part in the success of a software project development.Based on the practical project,a fine-grained human resource management model is introduced,which defines the human resource,software project,task and so on,as an entity which has states,attributes and operations.In addition,the data generated from the model provide support for the human resource plan,scheduling,conflict resolution,evaluation etc.A platform is developed based on this model,and a real case is studied through the platform to verify the validity of the model.

fine-grained;project management;human resource management

A

TP311

10.3778/j.issn.1002-8331.1604-0396

佛山市院市合作項目（No.2014HT100022）；廣州市珠江新星項目（No.201610010092）；廣東省科技計劃項目（No.2017A040405012）；南沙區(qū)科技項目（No.2016SF001）。

李引（1981—），男，博士，副研究員，研究領(lǐng)域為軟件構(gòu)件，云計算；劉東成（1987—），男，碩士，研究領(lǐng)域為軟件工程，食品溯源；袁峰（1977—），男，博士，碩士生導(dǎo)師，副研究員，研究領(lǐng)域為模型驅(qū)動，云計算，智慧城市；魏革（1972—），男，高級工程師，研究領(lǐng)域為信息安全，大數(shù)據(jù)；陽昕（1989—），女，碩士。

2016-04-28

2016-06-29

1002-8331（2017）21-0203-11

CNKI網(wǎng)絡(luò)優(yōu)先出版：2017-03-23,http://kns.cnki.net/kcms/detail/11.2127.TP.20170323.0832.018.html