專利名稱：一種項目計劃處理方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及Web服務(wù)技術(shù)領(lǐng)域，特別是涉及一種項目計劃處理方法及系統(tǒng)。
背景技術(shù)：
工作分解結(jié)構(gòu)(Work Breakdown Structure，以下簡稱WBS)是在項目管理中以可交付成果為導(dǎo)向?qū)椖恳剡M(jìn)行的分組，它歸納和定義了項目的整個工作范圍，每下降一層代表對項目工作更詳細(xì)的定義。目前，在項目管理等應(yīng)用領(lǐng)域，通常是由各級計劃人員對項目進(jìn)行WBS分解，然后通過會議等方式傳達(dá)到各個下級單位，以便由多個單位或單位內(nèi)部的部門協(xié)同完成項目計劃。例如，通常由各級計劃人員根據(jù)WBS進(jìn)行進(jìn)度、資源等的規(guī)劃與分配，將整個項目從第一級分解到最后一級。而在確定各級計劃時，一般是基于會議的方式進(jìn)行線下的溝通協(xié)調(diào)。 但是，對于一個規(guī)模大、參與單位多、層次多的項目而言，這種協(xié)調(diào)方式會比較費時費力，無法適應(yīng)這種大項目多層次、多單位的計劃協(xié)同。因此，迫切需要本領(lǐng)域技術(shù)人員解決的技術(shù)問題就是如何利用強(qiáng)大的計算機(jī)系統(tǒng)，對項目管理中的工作分解進(jìn)行支持，從而實現(xiàn)更高效的工作分解，以適應(yīng)于大項目多層次、多單位的計劃協(xié)同。

發(fā)明內(nèi)容
本發(fā)明提供一種項目計劃處理方法及系統(tǒng)，能夠借助于計算機(jī)系統(tǒng)，實現(xiàn)更高效的工作分解，進(jìn)而適應(yīng)于大項目多層次、多單位的計劃協(xié)同。為實現(xiàn)上述目的，本發(fā)明提供了如下方案—種項目計劃處理方法，在計劃的不同階段下發(fā)工作分解結(jié)構(gòu)WBS分解的項目計劃分解信息，對項目WBS計劃分解信息進(jìn)行逐級反饋，將協(xié)調(diào)后的項目計劃分解信息下發(fā)， 對各層的項目計劃分解信息進(jìn)行逐級確認(rèn)；其中，所述項目計劃分解信息包括任務(wù)量和相應(yīng)的進(jìn)度控制數(shù)；所述方法包括接收用戶的登錄請求，解析所述登錄請求以獲取用戶的身份信息；根據(jù)所述身份信息，向所述用戶展現(xiàn)上級下發(fā)給該用戶的計劃任務(wù)；接收用戶針對所述計劃任務(wù)提交的管理請求，并確定所述管理請求對應(yīng)的項目計劃分解信息狀態(tài)；針對所述管理請求及所述項目計劃分解信息狀態(tài)產(chǎn)生相應(yīng)的事件；將所述事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎，以便所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。其中所述管理請求包括新建項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括新建狀態(tài)；所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理包括
所述EDA引擎調(diào)用新建項目計劃分解信息的方法，產(chǎn)生分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者，以便完成下一級計劃的下發(fā)。其中所述管理請求包括修改項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括變更狀態(tài)；所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理包括所述EDA引擎調(diào)用變更項目計劃分解信息的方法，產(chǎn)生變更后的分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到相應(yīng)的執(zhí)行者。優(yōu)選地，所述項目計劃分解信息帶有版本號，所述方法還包括當(dāng)用戶讀取項目計劃分解信息時，獲取該項目計劃分解信息在該讀取時刻的第一版本號；當(dāng)接收到用戶提交的攜帶有所述第一版本號的修改項目計劃分解信息請求時，從該請求中解析出所述第一版本號，并獲取該項目計劃分解信息在該請求提交時刻的第二版本號；判斷所述第一版本號與第二版本號是否一致，如果一致，則將所述項目計劃分解信息的版本號增加，并接受該修改請求；否則，拒絕該修改請求。優(yōu)選地，所述方法還包括當(dāng)用戶需要對所述項目計劃分解信息進(jìn)行修改操作時，獲取針對該項目計劃分解信息建立的鎖，如果獲取到，則將所述項目計劃分解信息設(shè)置為可修改狀態(tài)，否則，則將所述項目計劃分解信息設(shè)置為不可修改狀態(tài)。優(yōu)選地，所述將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者之前還包括將各個分解后計劃任務(wù)向?qū)?yīng)的執(zhí)行者進(jìn)行預(yù)發(fā)布；當(dāng)接收到各個執(zhí)行者確認(rèn)的反饋信息后，執(zhí)行將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者的步驟。優(yōu)選地，所述確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者之后還包括向各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者發(fā)送通知消息。優(yōu)選地采用異步的處理方式向所述EDA發(fā)送產(chǎn)生的事件。一種項目計劃處理系統(tǒng)，在計劃的不同階段下發(fā)工作分解結(jié)構(gòu)WBS分解的項目計劃分解信息，對項目WBS計劃分解信息進(jìn)行逐級反饋，將協(xié)調(diào)后的項目計劃分解信息下發(fā)， 對各層的項目計劃分解信息進(jìn)行逐級確認(rèn)；其中，所述項目計劃分解信息包括任務(wù)量和相應(yīng)的進(jìn)度控制數(shù)；所述系統(tǒng)包括解析單元，用于接收用戶的登錄請求，解析所述登錄請求以獲取用戶的身份信息；展現(xiàn)單元，用于根據(jù)所述身份信息，向所述用戶展現(xiàn)上級下發(fā)給該用戶的計劃任務(wù)；請求接收單元，用于接收用戶針對所述計劃任務(wù)提交的管理請求，并確定所述管理請求對應(yīng)的項目計劃分解信息狀態(tài)；
事件產(chǎn)生單元，用于針對所述管理請求及所述項目計劃分解信息狀態(tài)產(chǎn)生相應(yīng)的事件；發(fā)送單元，用于將所述事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎，以便所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。其中所述管理請求包括新建項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括新建狀態(tài)；所述EDA引擎包括第一調(diào)用子單元，用于所述EDA引擎調(diào)用新建項目計劃分解信息的方法，產(chǎn)生分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者，以便完成下一級計劃的下發(fā)。其中所述管理請求包括修改項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括變更狀態(tài)；所述EDA引擎包括第二調(diào)用子單元，用于所述EDA引擎調(diào)用變更項目計劃分解信息的方法，產(chǎn)生變更后的分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到相應(yīng)的執(zhí)行者。優(yōu)選地，所述項目計劃分解信息帶有版本號，所述系統(tǒng)還包括第一獲取單元，用于當(dāng)用戶讀取項目計劃分解信息時，獲取該項目計劃分解信息在該讀取時刻的第一版本號；第二獲取單元，用于當(dāng)接收到用戶提交的攜帶有所述第一版本號的修改項目計劃分解信息請求時，從該請求中解析出所述第一版本號，并獲取該項目計劃分解信息在該請求提交時刻的第二版本號；判斷單元，用于判斷所述第一版本號與第二版本號是否一致，如果一致，則將所述項目計劃分解信息的版本號增加，并接受該修改請求；否則，拒絕該修改請求。優(yōu)選地，所述系統(tǒng)還包括鎖定單元，用于當(dāng)用戶需要對所述項目計劃分解信息進(jìn)行修改操作時，獲取針對該項目計劃分解信息建立的鎖，如果獲取到，則將所述項目計劃分解信息設(shè)置為可修改狀態(tài)，否則，則將所述項目計劃分解信息設(shè)置為不可修改狀態(tài)。 優(yōu)選地，所述系統(tǒng)還包括預(yù)發(fā)布單元，用于將各個分解后計劃任務(wù)向?qū)?yīng)的執(zhí)行者進(jìn)行預(yù)發(fā)布；反饋接收單元，用于當(dāng)接收到各個執(zhí)行者確認(rèn)的反饋信息后，執(zhí)行將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者的步驟。優(yōu)選地，所述系統(tǒng)還包括通知單元，用于確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者之后，向各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者發(fā)送通知消息。優(yōu)選地所述發(fā)送單元采用異步的處理方式向所述EDA發(fā)送產(chǎn)生的事件。根據(jù)本發(fā)明提供的具體實施例，本發(fā)明公開了以下技術(shù)效果在本發(fā)明中，能夠通過統(tǒng)一的計算機(jī)系統(tǒng)對項目計劃進(jìn)行管理，每一級計劃任務(wù)的執(zhí)行者都可以登錄該系統(tǒng)，從而獲得分配給該執(zhí)行者的計劃任務(wù)，該執(zhí)行者可以在該系統(tǒng)中對該計劃任務(wù)進(jìn)行管理(包括對當(dāng)前的計劃任務(wù)進(jìn)行再細(xì)分并下發(fā)、或者對項目計劃進(jìn)行的修改等)。系統(tǒng)在接收到執(zhí)行者的管理請求后，可以產(chǎn)生一事件，將該事件發(fā)送到事件驅(qū)動架構(gòu)(Event Driven Architecture，以下簡稱EDA)引擎去處理，進(jìn)而，EDA就可以調(diào)用該事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理即可。可見，在本發(fā)明中，每一級的業(yè)務(wù)執(zhí)行者都可以僅針對分配給自己的計劃任務(wù)進(jìn)行管理，對應(yīng)用系統(tǒng)而言，在處理用戶請求時， 采用了 EDA架構(gòu)，由于EDA弓丨擎與Web服務(wù)器中的業(yè)務(wù)邏輯系統(tǒng)是不同的模塊，可以部署于不同的服務(wù)器，因此，可以避免單服務(wù)器工作時帶來的性能瓶頸，為處理海量數(shù)據(jù)提供了可能。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖1是本發(fā)明實施例提供的多級計劃組織形式示意圖；圖2是本發(fā)明實施例提供的方法的流程圖；圖3是本發(fā)明實施例提供的多級計劃分解流程圖；圖4是本發(fā)明實施例提供的零級計劃分解流程圖；圖5是本發(fā)明實施例提供的一級計劃分解流程圖；圖6是本發(fā)明實施例提供的系統(tǒng)的示意圖。
具體實施例方式下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員所獲得的所有其他實施例，都屬于本發(fā)明保護(hù)的范圍。在本發(fā)明實施例中，為了實現(xiàn)高效地工作分解及管理，提供一種簡單、易推廣、滿足多層次、多層級協(xié)同管理要求的計劃編制方法，同時通過計算機(jī)技術(shù)和網(wǎng)絡(luò)技術(shù)實現(xiàn)計劃的逐級編制、審核、下發(fā)、反饋、發(fā)布過程，實現(xiàn)計劃的多級協(xié)同編制，以便提高計劃編制效率，提高計劃有效性、合理性以及可執(zhí)行性。參見圖1，本發(fā)明實施例中的計劃過程采取多級計劃的組織形式，以便進(jìn)行交互式迭代，由上到下逐級完成項目計劃，由上到下逐級下達(dá)計劃，由下到上反饋上報各級計劃， 每一級制定本級承擔(dān)的計劃分解工作，每一級計劃由相應(yīng)的計劃人員完成，經(jīng)本級單位領(lǐng)導(dǎo)審核通過后，下發(fā)下一級任務(wù)承擔(dān)單位。下一級任務(wù)承擔(dān)單位根據(jù)上級WBS計劃分解本單位執(zhí)行的WBS計劃，向上級上報本級、本單位負(fù)責(zé)的計劃，并根據(jù)下級的反饋和上級的計劃調(diào)整來修改調(diào)整本級、本單位負(fù)責(zé)的計劃。這樣，相當(dāng)于采用統(tǒng)一的計劃制定軟件平臺，實現(xiàn)了一種“兩上兩下”的計劃制定方式，從而實現(xiàn)多級、多組織、多層次協(xié)同的計劃制定模式。其中，“兩上兩下”分別是指，一下在計劃不同的階段向下逐級下發(fā)WBS任務(wù)量和相應(yīng)的進(jìn)度控制數(shù)；一上對計劃WBS分解的任務(wù)量和進(jìn)度控制數(shù)的向上級逐級反饋；二下將協(xié)調(diào)后計劃WBS任務(wù)量和進(jìn)度控制數(shù)再向下級逐級下發(fā)；二上對各層級的計劃WBS任務(wù)量和進(jìn)度控制數(shù)向上級逐級確認(rèn)，計劃正式發(fā)布。也就是說，通過各層級計劃的反復(fù)下發(fā)、反饋、確認(rèn)的迭代，通過計算機(jī)軟件在網(wǎng)絡(luò)環(huán)境中實現(xiàn)在同一網(wǎng)絡(luò)環(huán)境下計劃數(shù)據(jù)的共享，參與項目計劃的各級單位協(xié)同完成完整的項目計劃。下級計劃的變動不能直接引起上級計劃數(shù)據(jù)的變化，上級計劃的變動只能由上級計劃的制定者修改調(diào)整。在此過程中，數(shù)據(jù)的特點如下計劃的發(fā)布、審核、反饋、接收、上報等事件，會引起項目計劃分解信息的狀態(tài)變化，給相應(yīng)的處理人產(chǎn)生一個計劃任務(wù)，還可以同時給相關(guān)的人員發(fā)送通知消息。針對這種類型的數(shù)據(jù)，現(xiàn)有技術(shù)中常用的處理方式，是直接對每個事件編寫對應(yīng)的處理程序，以便處理計劃的更新、產(chǎn)生計劃任務(wù)和發(fā)送通知消息等等。但是這種方式的缺點在于業(yè)務(wù)邏輯完全嵌入在處理程序中，使得程序的擴(kuò)展性不強(qiáng)，并且在計算機(jī)的處理性能上容易產(chǎn)生瓶頸，并不適合于計劃數(shù)據(jù)量大、分布廣泛的現(xiàn)實狀況。為此，在本發(fā)明實施例中，提供了相應(yīng)的處理方案，參見圖2，本發(fā)明實施例提供的項目計劃處理方法包括以下步驟S201 接收用戶的登錄請求，解析所述登錄請求以獲取用戶的身份信息；在本發(fā)明實施例中，可以采用Web服務(wù)的方式實現(xiàn)，這樣，相當(dāng)于各級用戶可以通過Web頁面訪問Web服務(wù)器上保存的數(shù)據(jù)。具體實現(xiàn)時，由于每級用戶的權(quán)限以及需要承擔(dān)的任務(wù)都可能不同，因此，為了區(qū)分不同的用戶，可以設(shè)置為，需要在用戶登錄服務(wù)器之后， 才會訪問到相應(yīng)的內(nèi)容。為此，可以為用戶提供注冊用戶信息的入口，用戶從該入口注冊成功之后，服務(wù)器可以記錄用戶的注冊信息，并且用戶可以利用這些注冊信息登錄Web服務(wù)器。也就是說，對于一個已經(jīng)注冊過的用戶，可以在Web頁面上向Web服務(wù)器發(fā)起登錄請求(例如，通過輸入用戶名、密碼的方式)，Web服務(wù)器在接收到該登錄請求之后，就可以從中解析出用戶的身份信息，以便在后續(xù)的步驟中使用該信息。S202 根據(jù)所述身份信息，向所述用戶展現(xiàn)上級分配給該用戶的計劃任務(wù)；如前文所述，由于每一級在進(jìn)行項目計劃分解之后，由于在計劃的不同階段下發(fā) WBS分解的項目計劃分解信息，因此，對于某一級別的用戶X而言，當(dāng)其登錄到Web服務(wù)器之后，就可以看到上級下發(fā)給用戶的計劃任務(wù)。例如，某一級用戶接收到的計劃任務(wù)是任務(wù) A，該一級用戶將該任務(wù)A分解為任務(wù)Al、A2、A3之后，將其分別下發(fā)給其下級用戶X、Y、Z， 對于Web服務(wù)器而言，在完成下發(fā)之后，會保存任務(wù)與用戶之間的對應(yīng)關(guān)系；這樣，當(dāng)用戶X 使用自己的注冊信息登錄到Web服務(wù)器之后，Web服務(wù)器在解析出該用戶X的身份信息之后，就可以將上級用戶下發(fā)給該用戶X的計劃任務(wù)Al展現(xiàn)給該用戶X ；類似的，當(dāng)用戶Y或 Z使用自己的注冊信息登錄到Web服務(wù)器之后，Web服務(wù)器在解析出該用戶Y或Z的身份信息之后，就可以將上級用戶下發(fā)給該用戶Y或Z的計劃任務(wù)A2或A3展現(xiàn)給該用戶Y或Z。 為了便于描述，以下均以用戶X為例進(jìn)行介紹。S203 接收用戶針對所述計劃任務(wù)提交的管理請求，并確定所述管理請求對應(yīng)的項目計劃分解信息狀態(tài)；當(dāng)用戶X登錄到Web服務(wù)器，并看到自己的計劃任務(wù)Al之后，就可以對該計劃任務(wù)進(jìn)行管理。例如，包括對任務(wù)Al的進(jìn)一步分解，并向下級用戶進(jìn)行下發(fā)，或者，向上級用戶進(jìn)行反饋，或者對已經(jīng)分解的計劃進(jìn)行變更等等。因此，相應(yīng)的項目計劃分解信息狀態(tài)就可以包括項目計劃分解信息的新建、反饋、變更等等。也就是說，接收到的管理請求，可能是新建、反饋、變更等請求，對應(yīng)的項目計劃分解信息狀態(tài)也有新建、反饋、變更等。在接收到用戶提交的管理請求之后，可以將相關(guān)的信息保存到數(shù)據(jù)庫中。S204 針對所述管理請求及所述項目計劃分解信息狀態(tài)產(chǎn)生相應(yīng)的事件；在本發(fā)明實施例中，采用基于事件驅(qū)動的處理框架，也即，每次接收到用戶的一個管理請求，都可以產(chǎn)生相應(yīng)的事件，例如，當(dāng)接收到新建請求時，即可產(chǎn)生新建一個項目計劃分解信息的事件，當(dāng)接收到變更請求時，即可產(chǎn)生對當(dāng)前的項目計劃分解信息進(jìn)行修改的事件，等等。S205 將所述事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎，以便所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。在本發(fā)明實施例中，在針對用戶的管理請求產(chǎn)生了相應(yīng)的事件之后，并不是直接調(diào)用事件處理程序進(jìn)行處理，而是將事件發(fā)送到EDA引擎，有EDA引擎去調(diào)用相應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。其中，EDA是一種用于進(jìn)行設(shè)計和實現(xiàn)應(yīng)用和系統(tǒng)的方法，在這些應(yīng)用和系統(tǒng)里，事件所觸發(fā)的消息可以在獨立的、非耦合的組件和服務(wù)之間傳遞，這些模塊彼此并不知曉對方。這些應(yīng)用程序中的EDA極大地改進(jìn)了響應(yīng)不同的、表面上毫無關(guān)聯(lián)事件的能力。通過提供瞬時過濾、聚合和關(guān)聯(lián)事件等能力，EDA可以快速地檢測出事件并判斷它的類型，從而幫助組織機(jī)構(gòu)快速、恰當(dāng)?shù)仨憫?yīng)和處理這些事件。也就是說，在本發(fā)明實施例中，將EDA架構(gòu)應(yīng)用到項目計劃分解的過程中來，使得業(yè)務(wù)邏輯層與具體的事件處理層相分離，也就是說，主要的業(yè)務(wù)邏輯，包括請求的接收、信息的保存等可以由業(yè)務(wù)邏輯層來完成，而事件處理等附加的業(yè)務(wù)邏輯則可以由EDA引擎來完成。這樣，如果附加的業(yè)務(wù)邏輯需要發(fā)生變化，就可以改變對應(yīng)的事件處理器的配置，而不需要改動主業(yè)務(wù)邏輯層的程序，從而增強(qiáng)了程序的可擴(kuò)展性。其次，EDA引擎和業(yè)務(wù)邏輯層是不同的模塊，可以部署于不同的服務(wù)器，這就為處理海量數(shù)據(jù)提供了可能，避免單服務(wù)器帶來的性能瓶頸。另外，引入EDA引擎后，還可以對處理過程發(fā)生的事件進(jìn)行很好的跟蹤，統(tǒng)一進(jìn)行日志記錄等等。需要說明的是，在具體實現(xiàn)時，業(yè)務(wù)邏輯層產(chǎn)生的事件可以具有自己的ID，對于 EDA引擎而言，預(yù)先保存了各個事件的ID與事件處理方法之間的對應(yīng)關(guān)系，因此，在接收到一個事件之后，直接調(diào)用該事件的ID對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理即可。例如，當(dāng)管理請求為新建請求時，產(chǎn)生的事件是新建事件，則EDA引擎就會調(diào)用新建事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。具體實現(xiàn)時，如果用戶需要針對上一級下發(fā)給其的某計劃任務(wù)進(jìn)行進(jìn)一步地分解，則該用戶可以在Web頁面上錄入分解信息(例如前述例子中的將任務(wù)A分解為A1、A2、A3等等)，然后點擊“提交”等按鈕，這樣，Web服務(wù)器就可以接收到該新建請求。將項目計劃分解信息狀態(tài)確定為新建狀態(tài)，之后就可以產(chǎn)生一個新建事件，并將其發(fā)送給EDA引擎。EDA引擎在接收到該事件之后，就可以調(diào)用新建事件對應(yīng)的事件處理方法進(jìn)行處理。具體的處理過程可以包括產(chǎn)生分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者，以便完成下一級計劃的下發(fā)。當(dāng)然，為了使得下級執(zhí)行者能夠及時獲知有新任務(wù)到來，還可以同時向執(zhí)行者發(fā)送通知消息，例如，可以通過發(fā)送短消息等方式，使得用戶即使沒有在線，也可以獲知新任務(wù)的到來。當(dāng)管理請求為變更時，對應(yīng)的項目計劃分解信息狀態(tài)為變更狀態(tài)，因此，主業(yè)務(wù)邏輯會產(chǎn)生變更事件，并將其發(fā)送給EDA引擎，則EDA引擎就會調(diào)用變更事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。例如，當(dāng)用戶登錄到Web服務(wù)器看到上級下發(fā)給其的計劃任務(wù)，以及之前對該計劃任務(wù)的分解信息之后，如果需要對已經(jīng)分解的信息進(jìn)行修改，則可以在Web 頁面上提交修改后的分解信息，例如，以前是將任務(wù)A分解為A1、A2、A3，修改之后是將該任務(wù)A分解為Al、A2、A4，然后點擊“提交”等按鈕，這樣，Web服務(wù)器就可以接收到該變更請求，并將項目計劃分解信息狀態(tài)確定為變更狀態(tài)，之后就可以產(chǎn)生一個變更事件，并將其發(fā)送給EDA引擎。EDA引擎在接收到該事件之后，就可以調(diào)用變更事件對應(yīng)的事件處理方法進(jìn)行處理。具體的處理過程可以包括產(chǎn)生變更后的分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到相應(yīng)的執(zhí)行者。類似的，為了使得下級執(zhí)行者能夠及時獲知有新任務(wù)到來，還可以同時向執(zhí)行者發(fā)送通知消息，例如，可以通過發(fā)送短消息等方式，使得用戶即使沒有在線，也可以獲知新任務(wù)的到來。當(dāng)然，無論是在新建還是在變更的過程中，在具體的將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者之前，還可以將各個分解后計劃任務(wù)向?qū)?yīng)的執(zhí)行者進(jìn)行預(yù)發(fā)布，當(dāng)接收到各個執(zhí)行者確認(rèn)的反饋信息后，再執(zhí)行將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者的步驟。其中，關(guān)于主業(yè)務(wù)邏輯與EDA之間的事件發(fā)布方式，可以采用同步或者異步方式。 而在本發(fā)明的優(yōu)選實施例中，可以采用異步的處理方式，也就是說，當(dāng)主業(yè)務(wù)邏輯產(chǎn)生一個事件，并向EDA引擎發(fā)送之后，不需要等待EDA引擎的反饋，就可以向EDA引擎發(fā)送下一個新產(chǎn)生的事件。這樣，對于主業(yè)務(wù)邏輯層而言，只需要完成主業(yè)務(wù)邏輯就可以返回響應(yīng)結(jié)果，因此，可以使主業(yè)務(wù)邏輯層對用戶的響應(yīng)速度得到提升。總之，通過以上所述可見，本發(fā)明實施例能夠通過統(tǒng)一的計算機(jī)系統(tǒng)對項目計劃進(jìn)行管理，每一級計劃任務(wù)的執(zhí)行者都可以登錄該系統(tǒng)，從而獲得分配給該執(zhí)行者的計劃任務(wù)，該執(zhí)行者可以在該系統(tǒng)中對該計劃任務(wù)進(jìn)行管理(包括對當(dāng)前的計劃任務(wù)進(jìn)行細(xì)分的計劃分解并進(jìn)行下發(fā)、或者對項目計劃分解進(jìn)行的修改等等)。系統(tǒng)在接收到執(zhí)行者的管理請求后，可以產(chǎn)生一事件，將該事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎去處理，進(jìn)而，EDA就可以調(diào)用該事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理即可?？梢姡诒景l(fā)明中，每一級的業(yè)務(wù)執(zhí)行者都可以僅針對分配給自己的計劃任務(wù)進(jìn)行管理，對應(yīng)系統(tǒng)而言，在處理用戶請求時， 采用了 EDA架構(gòu)，由于EDA弓丨擎與Web服務(wù)器中的業(yè)務(wù)邏輯系統(tǒng)是不同的模塊，可以部署于不同的服務(wù)器，因此，可以避免單服務(wù)器工作時帶來的性能瓶頸，為處理海量數(shù)據(jù)提供了可能。在實際應(yīng)用中，可能存在這樣的情況同一項目計劃A同時下發(fā)給了用戶X和用戶 Y，用戶X和用戶Y都可以對項目計劃A進(jìn)行管理操作，包括進(jìn)行分解，或者進(jìn)行分解信息的變更等等。如果在某一時刻，用戶X和用戶Y都需要對項目計劃A進(jìn)行管理操作，則可能會發(fā)生沖突。例如，某用戶X在登錄到服務(wù)器之后，展現(xiàn)給該用戶的關(guān)于某項目計劃A當(dāng)前的分解信息是，分解為A1、A2、A3，用戶X需要將A3修改為A4 ；但是，由于修改的過程需要用戶手動地錄入新的分解信息，還需要經(jīng)過網(wǎng)絡(luò)傳輸才能到達(dá)服務(wù)器，這期間需要經(jīng)歷一定的時間周期。如果恰好是在這個時間段內(nèi)，用戶Y也對該項目計劃A的分解信息進(jìn)行了修改， 例如，假設(shè)將A3修改為A5，并且已經(jīng)在用戶X提交之前完成了修改的操作，則服務(wù)器在處理用戶X提交的修改請求時就會出錯，因為數(shù)據(jù)庫中已經(jīng)不存在A3這一項目計劃了。為了解決上述問題，需要在項目計劃分解的過程中，進(jìn)行并發(fā)控制，下面對此進(jìn)行詳細(xì)地介紹。在本發(fā)明實施例中，可以為項目計劃的分解信息生成版本號，也即對于某項目計劃而言，某用戶為其新建了項目計劃分解信息時，系統(tǒng)可以自動為其生成版本號，例如，新建時的版本號可以為1 ；當(dāng)用戶成功進(jìn)行第一次更新之后，可以將其版本號增加為2，以此類推。在用戶需要對某項目計劃的項目計劃分解信息進(jìn)行更新等操作時，系統(tǒng)在讀取項目計劃分解信息的同時，可以同時獲取該讀取時刻該分解信息的版本號。然后用戶可以在Web 界面上錄入新的項目計劃分解信息，當(dāng)用戶點擊“提交”等按鈕之后，服務(wù)器可以接收到用戶的修改請求，該提交請求中可以攜帶有讀取時刻的版本號；此時，服務(wù)器再去讀取該項目計劃分解信息當(dāng)前的版本號，并比較兩個時刻讀取到的版本號是否一致，如果一致，則可以繼續(xù)針對該用戶的修改請求進(jìn)行相應(yīng)的處理(包括保存修改后的分解信息，以及將分解信息的版本號增加等等)，如果不一致，則拒絕接受此次修改請求。為了更好地理解上述方案，下面結(jié)合例子進(jìn)行介紹。假設(shè)用戶X在Tl時刻登錄Web 服務(wù)器，讀取項目計劃A的分解信息時，記錄下其讀取時刻的版本號是1 ；用戶Y在T2時刻登錄Web服務(wù)器，讀取項目計劃A的分解信息時，記錄下其讀取時刻的版本號也為1。用戶 X在看到版本號為1的分解信息之后，需要對其進(jìn)行修改，錄入了新的分解信息之后，在T3 時刻將修改請求發(fā)送到Web服務(wù)器，該修改請求中攜帶有版本號1 ；Web服務(wù)器從修改請求中解析出版本號1，并重新去數(shù)據(jù)庫中獲取該項目計劃的當(dāng)前版本號，假設(shè)當(dāng)前版本號也為 1，則兩個版本號一致，因此，可以接受該用戶X的修改請求，同時，將該項目計劃的版本號修改為2。而用戶Y在看到版本號為1的分解信息之后，也需要進(jìn)行修改，并假設(shè)在時刻T4 提交了修改請求，其中，該修改請求中也攜帶有版本號1 ;Web服務(wù)器在接收到用戶Y的修改請求之后，從中解析出版本號1，同時去數(shù)據(jù)庫中讀取該項目計劃當(dāng)前的版本號，假設(shè)為2， 則兩個版本號不一致，因此可以拒絕用戶Y的修改請求。此時，對于用戶Y而言，可以采用刷新Web頁面等方式，重新向Web服務(wù)器發(fā)起讀取項目計劃分解信息的請求，Web服務(wù)器可以重新將版本號為2的分解信息展現(xiàn)給用戶Y，用戶Y可以在該版本號為2的分解信息基礎(chǔ)上，重新考慮是否需要進(jìn)行修改。當(dāng)然，在實際應(yīng)用中，還可能存在更為嚴(yán)重的沖突。例如，兩個用戶針對同一項目計劃提交管理請求的時間間隔非常短，即，在前述例子中，T3時刻與T4時刻很接近，則在接收到用戶X對某項目計劃A的修改請求時，發(fā)現(xiàn)兩個時刻的版本號都為1，在接收到用戶Y 對該項目計劃A的修改請求時，發(fā)現(xiàn)兩個時刻的版本號也是都為1，因此，用戶X和用戶Y的修改請求就都會被接受，但是，在具體將修改后的信息保存到數(shù)據(jù)庫中時，就會發(fā)生沖突， 造成保存失敗等現(xiàn)象。為此，本發(fā)明實施例還增加了鎖機(jī)制，當(dāng)用戶需要對所述項目計劃分解信息進(jìn)行修改操作時，需要首先去獲取針對該項目計劃分解信息建立的鎖，如果獲取到，則將項目計劃分解信息設(shè)置為可修改狀態(tài)，如果獲取不到，則將項目計劃分解信息設(shè)置為不可修改狀態(tài)。也就是說，如果某用戶獲取到對某項目計劃的修改權(quán)之后，就會將其鎖定，在鎖定解除之前，其他用戶無法對該項目計劃進(jìn)行修改操作，這樣就可以有效地避免前述沖突的發(fā)生。關(guān)于上述鎖機(jī)制，具體實現(xiàn)時，對于Web服務(wù)器采用單服務(wù)器方式實現(xiàn)的情況，可以采用內(nèi)存鎖的方式來實現(xiàn)。例如，可以利用Java語言里的synchronized關(guān)鍵字，并為每個項目計劃分解信息創(chuàng)建一個對象，從而為每個分解信息建立了內(nèi)存鎖。內(nèi)存鎖保證了在同一個JVM里，某個時刻只能有一個線程對某個項目計劃分解信息進(jìn)行修改，從而保證了修改信息的一致性。如果在分布式環(huán)境下，也即在具有多臺Web服務(wù)器的情況下，只需要將內(nèi)存鎖改成文件鎖即可，即共享文件服務(wù)器上的某個文件對應(yīng)的鎖?？傊?，在本發(fā)明實施例中，解決了計劃分解過程中出現(xiàn)海量數(shù)據(jù)時存在的問題，在解決了這些問題之后，即便在遇到海量數(shù)據(jù)時，也可以采用本發(fā)明實施例中“兩上兩下”的計劃制定模式。下面介紹上述“兩上兩下”的計劃制定模式在實際中的應(yīng)用。首先，參見圖3， 其為計劃制定過程中涉及的流程圖，其中，計劃本身逐級分為零級計劃、一級計劃、二級計劃.....N級計劃，具體的制定計劃的步驟可以包括步驟一、零級計劃制定后預(yù)發(fā)布，下發(fā)下級承擔(dān)單位；步驟二、預(yù)發(fā)布的零級計劃下發(fā)，由相關(guān)一級承擔(dān)單位確認(rèn)是否按此進(jìn)行，一級計劃單位若接受零級計劃或待定，則進(jìn)行本單位負(fù)責(zé)部分的一級計劃分解，然后預(yù)發(fā)布至二級計劃承擔(dān)單位，若不接受，則向上反饋。二級、三級依此類推；步驟三、每層級的計劃制定后，須經(jīng)本層級的計劃審核人員審核同意后預(yù)發(fā)布，再下發(fā)下級承擔(dān)單位進(jìn)行計劃確認(rèn)、分解，計劃審核人員包括總工程師、主任設(shè)計師、主管設(shè)計師等等；步驟四、各級計劃經(jīng)過上述下發(fā)、確認(rèn)、上報過程后，系統(tǒng)對所有計劃節(jié)點的狀態(tài)進(jìn)行檢查，如果均已處于確認(rèn)狀態(tài)，則由上至下發(fā)布計劃，項目基準(zhǔn)計劃完成。其中，零級計劃主要制定項目總的計劃分解目標(biāo)，其流程參見圖4，包括如下步驟步驟一、計劃編制人員根據(jù)合同或項目要求進(jìn)行WBS分解，形成零級計劃；步驟二、零級計劃需要通過主管領(lǐng)導(dǎo)如所長、總工程師等相關(guān)人員的審核，如審核通過，則將零級計劃下發(fā)下級承擔(dān)單位；如審核未通過，則修改調(diào)整零級計劃；步驟三、下發(fā)后的零級計劃，經(jīng)下級承擔(dān)單位接收確認(rèn)后反饋信息，零級計劃的編制單位綜合各承擔(dān)單位反饋的信息后，決定是否需要調(diào)整零級計劃。如需要調(diào)整修改，則重復(fù)上述過程；步驟四、零級計劃及各級計劃經(jīng)反復(fù)下發(fā)、確認(rèn)、審核后，由零級計劃編制單位正式發(fā)布零級計劃，下屬各級計劃逐級發(fā)布。多級計劃中的中間承擔(dān)單位負(fù)責(zé)一級、二級等計劃等，如圖5所示，其為一級計劃的流程，包括步驟一、一級計劃承擔(dān)單位根據(jù)零級計劃中本單位承擔(dān)的計劃節(jié)點制定一級計劃；步驟二、一級計劃經(jīng)本單位領(lǐng)導(dǎo)審核，如審核通過，則預(yù)發(fā)布本單位承擔(dān)的一級計劃；如審核未通過，則再修改調(diào)整一級計劃；步驟三、預(yù)發(fā)布的一級計劃下發(fā)各下級承擔(dān)單位，下級承擔(dān)單位確認(rèn)后反饋信息。一級計劃的承擔(dān)單位綜合下級反饋的信息，決定是否調(diào)整一級計劃。如不需調(diào)整，則上報零級計劃承擔(dān)單位；如需要修改，由計劃人員再行修改調(diào)整；步驟四、一級計劃及下屬各級計劃經(jīng)反復(fù)下發(fā)、確認(rèn)、審核后，在零級計劃發(fā)布后， 由上至下發(fā)布一級計劃。其他各級計劃也與上述類似，這里不再一一贅述?？傊?，上述總流程和子流程在計算機(jī)系統(tǒng)中，通過網(wǎng)絡(luò)環(huán)境實現(xiàn)計劃多級協(xié)同方式的分解制定。通過網(wǎng)絡(luò)環(huán)境和計算機(jī)系統(tǒng)實現(xiàn)計劃的分解、下發(fā)、上傳等，需要嚴(yán)格控制計劃分解和瀏覽的權(quán)限。根據(jù)安全保密的要求，一般可以約定上級可以瀏覽所屬下級的所有的計劃分解，下級只能瀏覽所負(fù)責(zé)計劃節(jié)點及其下屬分解計劃；每一層級的計劃節(jié)點均只能由該計劃節(jié)點的負(fù)責(zé)單位進(jìn)行分解，其它單位無權(quán)瀏覽和分解；每一層級承擔(dān)單位內(nèi)部分解計劃由指定的角色或人員進(jìn)行審核。上述總流程和子流程實現(xiàn)方法也可脫離網(wǎng)絡(luò)應(yīng)用環(huán)境?？梢曰谟嬎銠C(jī)系統(tǒng)，也適用于以介質(zhì)形式下發(fā)、上報各級任務(wù)的計劃方式，在計算機(jī)系統(tǒng)中可以將上報計劃的電子介質(zhì)逐級匯總，也可以將計劃以電子介質(zhì)的形式分級下發(fā)。與本發(fā)明實施例提供的項目計劃處理方法相對應(yīng)，本發(fā)明實施例還提供了一種項目計劃處理系統(tǒng)，該系統(tǒng)用于，在計劃的不同階段下發(fā)工作分解結(jié)構(gòu)WBS分解的項目計劃分解信息，對項目WBS計劃分解信息進(jìn)行逐級反饋，將協(xié)調(diào)后的項目計劃分解信息下發(fā)，對各層的項目計劃分解信息進(jìn)行逐級確認(rèn)；其中，所述項目計劃分解信息包括任務(wù)量和相應(yīng)的進(jìn)度控制數(shù)；參見圖6，該系統(tǒng)包括解析單元601，用于接收用戶的登錄請求，解析所述登錄請求以獲取用戶的身份信息；展現(xiàn)單元602，用于根據(jù)所述身份信息，向所述用戶展現(xiàn)上級下發(fā)給該用戶的計劃任務(wù)；請求接收單元603，用于接收用戶針對所述計劃任務(wù)提交的管理請求，并確定所述管理請求對應(yīng)的項目計劃分解信息狀態(tài)；事件產(chǎn)生單元604，用于針對所述管理請求及所述項目計劃分解信息狀態(tài)產(chǎn)生相應(yīng)的事件；發(fā)送單元605，用于將所述事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎，以便所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。其中，管理請求可以包括新建項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括新建狀態(tài)；所述EDA引擎包括第一調(diào)用子單元，用于所述EDA引擎調(diào)用新建項目計劃分解信息的方法，產(chǎn)生分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者，以便完成下一級計劃的下發(fā)。管理請求也可以包括修改項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括變更狀態(tài)；所述EDA引擎包括
第二調(diào)用子單元，用于所述EDA引擎調(diào)用變更項目計劃分解信息的方法，產(chǎn)生變更后的分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到相應(yīng)的執(zhí)行者。為了處理并發(fā)控制問題，所述項目計劃分解信息可以帶有版本號，此時，該系統(tǒng)還可以包括第一獲取單元，用于當(dāng)用戶讀取項目計劃分解信息時，獲取該項目計劃分解信息在該讀取時刻的第一版本號；第二獲取單元，用于當(dāng)接收到用戶提交的攜帶有所述第一版本號的修改項目計劃分解信息請求時，從該請求中解析出所述第一版本號，并獲取該項目計劃分解信息在該請求提交時刻的第二版本號；判斷單元，用于判斷所述第一版本號與第二版本號是否一致，如果一致，則將所述項目計劃分解信息的版本號增加，并接受該修改請求；否則，拒絕該修改請求。為了更好地處理并發(fā)沖突，該系統(tǒng)進(jìn)一步還可以包括鎖定單元，用于當(dāng)用戶需要對所述項目計劃分解信息進(jìn)行修改操作時，獲取針對該項目計劃分解信息建立的鎖，如果獲取到，則將所述項目計劃分解信息設(shè)置為可修改狀態(tài)，否則，則將所述項目計劃分解信息設(shè)置為不可修改狀態(tài)。在一種優(yōu)選的實施方式下，該系統(tǒng)還可以包括預(yù)發(fā)布單元，用于將各個分解后計劃任務(wù)向?qū)?yīng)的執(zhí)行者進(jìn)行預(yù)發(fā)布；反饋接收單元，用于當(dāng)接收到各個執(zhí)行者確認(rèn)的反饋信息后，執(zhí)行將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者的步驟。為了使得下級執(zhí)行者及時獲知新分配的項目計劃，該系統(tǒng)還可以包括通知單元，用于確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者之后，向各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者發(fā)送通知消息。為了提高響應(yīng)速度發(fā)送單元605可以采用異步的處理方式向所述EDA發(fā)送產(chǎn)生的事件?？傊?，本發(fā)明實施例提供的系統(tǒng)能夠通過統(tǒng)一的計算機(jī)系統(tǒng)對項目計劃進(jìn)行管理，每一級計劃任務(wù)的執(zhí)行者都可以登錄該系統(tǒng)，從而獲得分配給該執(zhí)行者的計劃任務(wù)，該執(zhí)行者可以在該系統(tǒng)中對該計劃任務(wù)進(jìn)行管理(包括對當(dāng)前的計劃任務(wù)進(jìn)行細(xì)分的計劃分解并進(jìn)行下發(fā)、或者對項目計劃分解進(jìn)行的修改等等)。系統(tǒng)在接收到執(zhí)行者的管理請求后，可以產(chǎn)生一事件，將該事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎去處理，進(jìn)而，EDA就可以調(diào)用該事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理即可?？梢姡诒景l(fā)明中，每一級的業(yè)務(wù)執(zhí)行者都可以僅針對分配給自己的計劃任務(wù)進(jìn)行管理，對應(yīng)系統(tǒng)而言，在處理用戶請求時，采用了 EDA架構(gòu)，由于EDA引擎與Web服務(wù)器中的業(yè)務(wù)邏輯系統(tǒng)是不同的模塊，可以部署于不同的服務(wù)器，因此，可以避免單服務(wù)器工作時帶來的性能瓶頸，為處理海量數(shù)據(jù)提供了可能。以上對本發(fā)明所提供的一種項目計劃處理方法及系統(tǒng)，進(jìn)行了詳細(xì)介紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施方式進(jìn)行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想， 在具體實施方式
及應(yīng)用范圍上均會有改變之處。綜上所述，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。
權(quán)利要求
1.一種項目計劃處理方法，其特征在于，在計劃的不同階段下發(fā)工作分解結(jié)構(gòu)WBS分解的項目計劃分解信息，對項目WBS計劃分解信息進(jìn)行逐級反饋，將協(xié)調(diào)后的項目計劃分解信息下發(fā)，對各層的項目計劃分解信息進(jìn)行逐級確認(rèn)；其中，所述項目計劃分解信息包括任務(wù)量和相應(yīng)的進(jìn)度控制數(shù)；所述方法包括接收用戶的登錄請求，解析所述登錄請求以獲取用戶的身份信息；根據(jù)所述身份信息，向所述用戶展現(xiàn)上級下發(fā)給該用戶的計劃任務(wù)；接收用戶針對所述計劃任務(wù)提交的管理請求，并確定所述管理請求對應(yīng)的項目計劃分解信息狀態(tài)；針對所述管理請求及所述項目計劃分解信息狀態(tài)產(chǎn)生相應(yīng)的事件；將所述事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎，以便所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于所述管理請求包括新建項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括新建狀態(tài)；所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理包括所述EDA引擎調(diào)用新建項目計劃分解信息的方法，產(chǎn)生分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者，以便完成下一級計劃的下發(fā)。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于 所述管理請求包括修改項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括變更狀態(tài)；所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理包括所述EDA引擎調(diào)用變更項目計劃分解信息的方法，產(chǎn)生變更后的分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者， 并將各個分解后計劃任務(wù)下發(fā)到相應(yīng)的執(zhí)行者。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述項目計劃分解信息帶有版本號，所述方法還包括當(dāng)用戶讀取項目計劃分解信息時，獲取該項目計劃分解信息在該讀取時刻的第一版本號；當(dāng)接收到用戶提交的攜帶有所述第一版本號的修改項目計劃分解信息請求時，從該請求中解析出所述第一版本號，并獲取該項目計劃分解信息在該請求提交時刻的第二版本號；判斷所述第一版本號與第二版本號是否一致，如果一致，則將所述項目計劃分解信息的版本號增加，并接受該修改請求；否則，拒絕該修改請求。
5.根據(jù)權(quán)利要求3或4所述的方法，其特征在于，所述方法還包括當(dāng)用戶需要對所述項目計劃分解信息進(jìn)行修改操作時，獲取針對該項目計劃分解信息建立的鎖，如果獲取到，則將所述項目計劃分解信息設(shè)置為可修改狀態(tài)，否則，則將所述項目計劃分解信息設(shè)置為不可修改狀態(tài)。
6.根據(jù)權(quán)利要求2至4任一項所述的方法，其特征在于，所述將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者之前還包括將各個分解后計劃任務(wù)向?qū)?yīng)的執(zhí)行者進(jìn)行預(yù)發(fā)布；當(dāng)接收到各個執(zhí)行者確認(rèn)的反饋信息后，執(zhí)行將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者的步驟。
7.根據(jù)權(quán)利要求2至4任一項所述的方法，其特征在于，所述確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者之后還包括向各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者發(fā)送通知消息。
8.根據(jù)權(quán)利要求1至4任一項所述的方法，其特征在于采用異步的處理方式向所述 EDA發(fā)送產(chǎn)生的事件。
9.一種項目計劃處理系統(tǒng)，其特征在于，在計劃的不同階段下發(fā)工作分解結(jié)構(gòu)WBS分解的項目計劃分解信息，對項目WBS計劃分解信息進(jìn)行逐級反饋，將協(xié)調(diào)后的項目計劃分解信息下發(fā)，對各層的項目計劃分解信息進(jìn)行逐級確認(rèn)；其中，所述項目計劃分解信息包括任務(wù)量和相應(yīng)的進(jìn)度控制數(shù)；所述系統(tǒng)包括解析單元，用于接收用戶的登錄請求，解析所述登錄請求以獲取用戶的身份信息；展現(xiàn)單元，用于根據(jù)所述身份信息，向所述用戶展現(xiàn)上級下發(fā)給該用戶的計劃任務(wù)；請求接收單元，用于接收用戶針對所述計劃任務(wù)提交的管理請求，并確定所述管理請求對應(yīng)的項目計劃分解信息狀態(tài)；事件產(chǎn)生單元，用于針對所述管理請求及所述項目計劃分解信息狀態(tài)產(chǎn)生相應(yīng)的事件；發(fā)送單元，用于將所述事件發(fā)送到事件驅(qū)動架構(gòu)EDA引擎，以便所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。
10.根據(jù)權(quán)利要求9所述的系統(tǒng)，其特征在于所述管理請求包括新建項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括新建狀態(tài)；所述EDA引擎包括第一調(diào)用子單元，用于所述EDA引擎調(diào)用新建項目計劃分解信息的方法，產(chǎn)生分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者，以便完成下一級計劃的下發(fā)。
11.根據(jù)權(quán)利要求9所述的系統(tǒng)，其特征在于所述管理請求包括修改項目計劃分解信息的請求，所述項目計劃分解信息狀態(tài)包括變更狀態(tài)；所述EDA引擎包括第二調(diào)用子單元，用于所述EDA引擎調(diào)用變更項目計劃分解信息的方法，產(chǎn)生變更后的分解后計劃任務(wù)，并根據(jù)預(yù)先配置的任務(wù)與執(zhí)行者之間的對應(yīng)關(guān)系，確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者，并將各個分解后計劃任務(wù)下發(fā)到相應(yīng)的執(zhí)行者。
12.根據(jù)權(quán)利要求11所述的系統(tǒng)，其特征在于，所述項目計劃分解信息帶有版本號，所述系統(tǒng)還包括第一獲取單元，用于當(dāng)用戶讀取項目計劃分解信息時，獲取該項目計劃分解信息在該讀取時刻的第一版本號；第二獲取單元，用于當(dāng)接收到用戶提交的攜帶有所述第一版本號的修改項目計劃分解信息請求時，從該請求中解析出所述第一版本號，并獲取該項目計劃分解信息在該請求提交時刻的第二版本號；判斷單元，用于判斷所述第一版本號與第二版本號是否一致，如果一致，則將所述項目計劃分解信息的版本號增加，并接受該修改請求；否則，拒絕該修改請求。
13.根據(jù)權(quán)利要求11或12所述的系統(tǒng)，其特征在于，所述系統(tǒng)還包括鎖定單元，用于當(dāng)用戶需要對所述項目計劃分解信息進(jìn)行修改操作時，獲取針對該項目計劃分解信息建立的鎖，如果獲取到，則將所述項目計劃分解信息設(shè)置為可修改狀態(tài)，否則，則將所述項目計劃分解信息設(shè)置為不可修改狀態(tài)。
14.根據(jù)權(quán)利要求10至12任一項所述的系統(tǒng)，其特征在于，所述系統(tǒng)還包括預(yù)發(fā)布單元，用于將各個分解后計劃任務(wù)向?qū)?yīng)的執(zhí)行者進(jìn)行預(yù)發(fā)布；反饋接收單元，用于當(dāng)接收到各個執(zhí)行者確認(rèn)的反饋信息后，執(zhí)行將各個分解后計劃任務(wù)下發(fā)到對應(yīng)的執(zhí)行者的步驟。
15.根據(jù)權(quán)利要求10至12任一項所述的系統(tǒng)，其特征在于，所述系統(tǒng)還包括通知單元，用于確定各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者之后，向各個分解后計劃任務(wù)對應(yīng)的執(zhí)行者發(fā)送通知消息。
16.根據(jù)權(quán)利要求9至12任一項所述的系統(tǒng)，其特征在于所述發(fā)送單元采用異步的處理方式向所述EDA發(fā)送產(chǎn)生的事件。
全文摘要
本發(fā)明公開了一種項目計劃處理方法及系統(tǒng)，其中，所述方法包括接收用戶的登錄請求，解析所述登錄請求以獲取用戶的身份信息；根據(jù)所述身份信息，向所述用戶展現(xiàn)上級下發(fā)給該用戶的計劃任務(wù)；接收用戶針對所述計劃任務(wù)提交的管理請求，確定所述管理請求對應(yīng)的項目計劃分解信息狀態(tài)；針對所述管理請求及所述項目計劃分解信息狀態(tài)產(chǎn)生相應(yīng)的事件；將所述事件發(fā)送到事件驅(qū)動架構(gòu)(Event Driven Architecture，簡稱EDA)引擎，以便所述EDA引擎調(diào)用所述事件對應(yīng)的事件處理方法進(jìn)行相應(yīng)的處理。通過本發(fā)明，能夠借助于計算機(jī)系統(tǒng)，實現(xiàn)更高效的工作分解，進(jìn)而適應(yīng)于大項目多層次、多單位的計劃協(xié)同。
文檔編號G06Q10/00GK102169562SQ201110093780
公開日2011年8月31日 申請日期2011年4月14日 優(yōu)先權(quán)日2011年4月14日
發(fā)明者張洪光, 鮑樂群, 黃云峰 申請人:泛太領(lǐng)時科技(北京)有限公司