維護人員的指派演算法

進行維護過程時，對於維護人員選擇的指派步驟，我們必須對工作紀錄的某一筆 紀錄，判讀各個元素和關係，才能得出適合的人員行使工作角色，下表 3 為演算法中 使用之函數及功能說明。

表 3.函數及功能說明表

函數 功能說明

T_log(P_i) 專案 Pi內需被維護之工作的工作紀錄，而此一紀錄 資料包含：群組別、專案別、人員與工作角色確實 指 派 (Group_UTRA) 、 人 員 與 工 作 角 色 未 被 指 派 (Group_UTRnA)等四筆資料欄位

Group_UTRA 人員與工作角色確實指派，包含：群組人員(U)、工 作角色(rt)

Group_UTRnA 人員與工作角色未被指派，包含：群組人員(U)、工 作角色(rt)

URA Pi 專案 Pi內，工作人員與角色指派關係，包含有：群 組人員(U)、工作角色(rt)

T_log(Pi)→Group_UTRA 將 T_log(Pi)中之人員真實指派關係(Group_UTRA) 選擇作為判斷

在此令演算法中“x→y”表示 x 所包含的元素值 y，加以取出作判斷；如 T_log(Pi)

→Group_UTRA，表示關於專案 Pi工作紀錄資料的元素 Group_UTRA，將其取出作判 斷。以下為本研究所呈現之群組工作維護的存取控制模型之維護人員指派演算法，如 圖 15 所示。

Algorithm URA_task

Input：T_log(Pi)、U //需被維護工作其紀錄和所有人員

Output：If success, return URA Pi //回傳人員-角色分派或無匹配人員 else fail。

Begin

URA Pi = null //清空專案 Pi的人員角色指派紀錄 Ux =(T_log(Pi )→Group_UTRA)→U //令專案 Pi的人員-角色紀錄中

的人員為 Ux

If (Ux is available) then //若 Ux可行使

{URA Pi = (T_log(Pi)→Group_UTRA) //令人員-角色紀錄為回傳值 return URA Pi } //回傳專案 Pi可行使之

人員與需求角色

UY= (T_log(Pi)→Group_UTRnA)→U //令專案 Pi的人員－角色紀錄中 能執行專案 Pi的人員為 UY

If (UY is not null) then //又若原屬群組人員 UY中 有人員可以執行專案 Pi

If (any user in UY is available) then

{ URA Pi = ((available UY of Group_UTRnA)∩(T_log(Pⁱ)→Group_UTRnA))

//人員角色指派=可指派的候選人員 Return URA Pi } //回傳專案 Pi角色可行使之 人員與需求角色

UZ=U - Ux - UY //全部人員-原先可行使 工作角色的人員

If (U_z is not null) then

If (any user in U_Z is available) then

{URA Pi = (available UZ assign to (T_log(Pi)→Group_UTRnA))

Return URA Pi } //回傳專案 Pi的工作角色可行使 之人員與需求角色

Else

Return Fail //無匹配人員 End

圖 15.需進行維護的工作之人員演算法

演算法的目標，是找到行使工作維護所需求的人員，或是透過失敗訊息知曉公司 無可工作維護的人員。在運算的過程必須用到須被維護的工作所屬之工作紀錄 (T_log(Projecti))、所有人員(U)。演算法的設計是基於職務熟悉作為依據，我們一開 始 先 從 工 作 紀 錄 (T_log(Projecti)) 中 ， 原 本 行 使 該 工 作 的 人 員 其 指 派 關 係 (Group_UTRA)，找尋原先人員(Ux)判別是否能進行需要被維護的工作，在人員可擔 任的情況下，將其指定為維護人員，行使角色進行工作維護。若原本行使該工作的人 員 無 法 行使 角 色， 那 麼 從 工 作 群 組 人 員 中 ， 可 行 使工 作 角 色 但 未 被 指 派 關 係 (Group_UTRnA)，找尋群組人員(UY)進行是否能工作維護的判別，在人員可擔任的情 況下，將其指定為維護人員，擔任角色進行工作維護。若此一人員仍然無法擔任角色，

那麼從公司人員(U)內，找尋公司人員(Uz)進行是否能工作維護的判別，當任意人員可

擔任的情況下，將其指定為維護人員，行使角色進行工作維護。若皆無法行使角色則 為無匹配人員，將告知系統管理員此一情形。

3.4 專案 專案 專案 專案工作 工作 工作 工作的 的 的 的維護 維護 維護 維護之 之 之 之假設個 假設個 假設個案 假設個 案 案探討 案 探討 探討 探討

本小節將以數個專案工作在工作維護的階段，來探討工作維護的人員選擇過程，

本研究未探討各個專案工作對於公司的相對權重，因此並未給予最佳化的人員選擇指 派，僅對群組與工作維護時的人員需求加以描述。

Empty 公司從成立至今，總共有 3 個開發專案，而 Empty 公司先後組織了 2 個專 案群組來對應並且完成這些工作，而出現在各個群組的工作角色，由於工作職能的關 係，Empty 公司設定程式撰寫工程師與系統測試工程師為角色互斥。各個專案群組的 工作內容與人員可行使角色如表 4 至表 8 所示：

表 4.人員可行使之工作角色表 可行使之工作角色

人員名稱 專案經理 程式撰寫工程師 系統測試工程師 系統整合工程師

Andy Yes No Yes Yes

Bob No Yes No No

Chris Yes Yes Yes No

David No No No Yes

Eric No Yes No Yes

Emily Yes No Yes Yes

Tom Yes No No No

Emmy No No Yes No

表 5.各專案與群組之工作內容表 專案需求之工作內容

專案代號 群組代碼 專案管理 程式撰寫 系統測試 系統整合 Project1 1 Yes Yes Yes Yes

Project2 1 Yes Yes Yes Yes

Project3 2 No Yes Yes No

表 6.專案 1 之工作紀錄表

專案 群組編號 工作名稱 需求角色 行使人員

Project1 Group1 專案管理 專案經理 Andy 程式撰寫 程式撰寫工程師 Bob 系統測試 系統測試工程師 Chris 系統整合 系統整合工程師 David

表 7.專案 2 之工作紀錄表

專案 群組編號 工作名稱 需求角色 行使人員

Project2 Group1 專案管理 專案經理 Chris 程式撰寫 程式撰寫工程師 Bob 系統測試 系統測試工程師 Andy 系統整合 系統整合工程師 David

表 8.專案 3 之工作紀錄表

專案 群組編號 工作名稱 需求角色 行使人員

Project3 Group2 程式撰寫 程式撰寫工程師 Eric 系統測試 系統測試工程師 Emily

以下為各個專案群組與工作角色的描述：

專案 1 為合作廠商外包的系統開發，對應至專案群組 1。故專案群組 1 需要的工 作內容有專案管理、程式撰寫、系統測試、系統整合，而企業人員中對照，由 Andy 行使專案經理角色、Bob 行使程式撰寫工程師角色、Chris 行使系統測試工程師角色、

David 行使系統整合工程師。若專案內的工作需要維護的時候，而原先行使工作角色 的人員因故無法執行，則從群組內選擇該角色的替代人員進行工作維護，各替代人員 分別為：專案經理之替代人員為 Chris、程式撰寫工程師之替代人員為 Chris、系統測 試工程師之替代人員為 Andy、系統整合工程師之替代人員為 Andy。

專案 2 為公司自身產品的開發，對應至專案群組 1。由 Chris 行使專案經理角色、

Bob 行使程式撰寫工程師角色、David 行使系統測試工程師角色、Eric 行使系統整合 工程師。專案需要維護時，各工作角色的替代人員分別為：專案經理之替代人員為 Andy、程式撰寫工程師之替代人員為 Chris (Andy 行使系統測試工程師角色與之互 斥)、系統測試工程師之替代人員為 Chris、系統整合工程師之替代人員為 Andy。

專案 3 為公司自身的系統開發，對應至專案群組 2。而在專案群組 2 需要的工作 內容為程式撰寫、系統測試，從企業人員對照後，由 Eric 行使系統測試工程師、Emily 行使程式撰寫工程師。由於程式撰寫與系統測試有工作職能的互斥關係，使得專案 3 的工作角色不存有專案群組內之替代人員。

假設此時專案 1 因為功能服務之變更，需求專案管理之工作維護、而專案 2 因為 產品整合之擴充，需要系統整合工作之維護、專案 3 因為系統擴充而需要系統測試之 工作維護，而 Empty 公司因為職能訓練將 David 派遣出差，因此 David 將暫時無法行 使任何工作角色。對於三個工作維護的產生，Empty 公司將專案 1、專案 2、專案 3 分別進行工作維護的人員選擇指派，而產生以下結果：

對於專案 1 需求角色專案經理，將會由原先行使工作人員之 Andy 行使之。

專案 2 需求角色系統整合工程師，由於原先行使工作角色的 David 被公司派遣出 差，同時替代人員 Andy 正在進行專案 1 的專案經理之工作維護，因此專案群組內並

沒有適合進行工作維護的人員，因此演算法找尋了企業組織內適合的人選 Emily，將 其建議其做為系統整合工作的工作維護人員。

而專案 3 需要系統測試之工作維護，此時原先行使人員 Emily 若被指派至專案 2 之工作維護，將造成原先行使人員之空缺，同時專案群組內並無替代人元可進行維 護，所以系統將會重新尋找企業人員中，可以擔任系統測試的人，以進行系統測試之 工作維護。若從該工作結束至產生需要維護此工作的這段時間內，企業並無新增適合 的人員，那將會告知群組管理員該工作無適合的人員可進行工作維護。

透過系統的判斷，群組管理員便能得知該工作群組負責維護工作之目前是否有人 員可以執行，進而尋求幫助或調配人員。而本演算法在同一時間僅能考慮一個工作維 護，並不做工作維護最佳化的人員選擇。

3.5 研究分析 研究分析 研究分析 研究分析

本研究的主要目的，是提出一套基於群組工作維護的存取控制模型，以解決需要 工作維護時，人員無法行使工作角色時造成的工作延宕，以及尋找適合該工作維護人 員的問題，目前僅針對單一時間點，進行單一工作進行人員的選擇，並未同時對多數 個工作進行最佳化的人員選擇和判斷，因此未來相關研究將會朝向同時指派多數個工 作人員，並針對其重要程度給予最佳化的人員指派關係。

群組管理員的輔助，能降低系統管理員的負擔，同時針對人員離開的情境，給予 候選人員，使在進行工作維護時，不會因為臨時有人員無法行使角色而產生無法預期 的情況。而現實情境中，原本擔任角色的人員，有可能受到專案或其他因素而無法調 配進行維護，此時我們針對已完成的工作所需的工作角色加以分析，透過工作任務紀 錄的候選人員，使群組管理員能授權指派適合的人員繼續行使角色，完成工作維護。

工作紀錄能讓專案工作在執行完畢後有完整的工作紀錄，方便我們進行工作維護時，

判斷該工作維護的需求，讓群組管理員加以指派。本研究中，並未設計角色和權限委

任的概念，僅用管理員授權和演算法進行人員選擇的概念，主要是由於委任必須有嚴 格的安全政策限制，以防止權限的過度遞移和濫用。

在本研究中，明確的指出了專案內的工作在完成時的工作記錄檔，能有效的紀錄 該工作的人員角色指派與角色權限指派等關係，利用這樣的功能，可以迅速的了解所 欲維護的工作，並針對人員和資源加以管控。同時在行使該工作的原先角色，我們設 計了候選人員的概念，當原先人員離職或無法行使原任務角色時，能有他人遞補或通 知管理員，不造成工作無人執行的情形。

在現實的企業內，公司人員的流失會使我們難以掌握確切的關鍵技術人員，而維 護進行的過程中，若有多數工作重複需求相同的工作角色，而公司內能行使的人員數 不足，很可能會使得工作因此延宕。面對此一問題，公司能透過工作紀錄，可以發現 經常使用的關鍵角色，以及透過系統可發現企業組織內重要工作角色，而加以培訓員 工能力。

3.6 小 小 小 小結 結 結 結

為了讓企業對於已完成專案在工作的維護上，有迅速而正確的指派能力，本研究 設計了一套適用於工作維護的存取控制模型，定義了模型中之人員、工作角色、權限、

群組、專案、以及工作紀錄等元素，同時描述使用者對於工作角色的指派和隱含關係。

在過往根據基於角色存取控制與工作流程的相關研究中，多數為探討存取規則的 訂立或是流程內各個工作的交互關係，而本研究將則將兩者融合，同時更著重於專案 內各個工作的維護，並依照職務的熟悉度將維護人員分為原始行使人員、群組內人員 以及企業內人員三類，讓企業透過演算法在指派過程能有分層而正確的工作維護人員 選擇之指派。

企業營運多數皆有職能衝突之工作，因此本研究設計了職能衝突時，加以分開的