變更管理和ibm rational clearquest
在變更管理領(lǐng)域，使用軟件工具并定義工具提供的自動(dòng)化操作過(guò)程可以提供巨大的好處，從而可以幫助聯(lián)系和協(xié)調(diào)開(kāi)發(fā)組織內(nèi)部不同的小組和團(tuán)隊(duì)，不管他們是在同一個(gè)寫字樓，還是分布在世界各地。
比如，如果一個(gè)客戶與一個(gè)產(chǎn)品支持代表談話并提出一個(gè)需要請(qǐng)求變更的問(wèn)題，那么這個(gè)變更管理解決方案不僅能使這個(gè)支持代表可以提交一個(gè)變更請(qǐng)求，還能夠讓這個(gè)開(kāi)發(fā)組織中適當(dāng)?shù)纳姹娮詣?dòng)接受到這個(gè)提交的通知，這樣使他們能夠進(jìn)行優(yōu)先級(jí)劃分并盡可能高效地響應(yīng)這些問(wèn)題，從而提出一個(gè)合適的解決方案。
ibm rational 在變更管理方面的需求
像許多其它全球性企業(yè)的開(kāi)發(fā)小組一樣，ibm rational開(kāi)發(fā)組織也需要一個(gè)能夠在分布式環(huán)境中工作的cm系統(tǒng)。這個(gè)系統(tǒng)必須不僅能為開(kāi)發(fā)者服務(wù)，還要能夠服務(wù)于質(zhì)量工程師、管理人員、客戶支持人員、信息開(kāi)發(fā)者，以其他任何與缺陷或者增強(qiáng)需求(rfe)相關(guān)的變更請(qǐng)求(cr)有關(guān)的涉眾。
ibm rational 利用 clearquest 來(lái)管理它自己的和 clearquest 產(chǎn)品本身相關(guān)的變更請(qǐng)求。我們的cm系統(tǒng)是著名的 ratlc，是由 ibm rational 內(nèi)部部署小組開(kāi)發(fā)的，它的名字來(lái)源于用戶數(shù)據(jù)庫(kù)的主方案。
有了這個(gè)系統(tǒng)，變更請(qǐng)求可以是來(lái)自各種涉眾的。比如：
這些僅僅是 ibm rational 開(kāi)發(fā)組織中的小組成員利用 clearquest 創(chuàng)建變更請(qǐng)求的眾多方法中的一部分。每個(gè)變更請(qǐng)求隨后都會(huì)經(jīng)過(guò)評(píng)估、分配、處理、然后被解決、修正和關(guān)閉的過(guò)程
ratlc 的使命
ibm rational 開(kāi)發(fā)組織的cm需求應(yīng)該都屬于 ratlc 的使命，ratlc 的使命是建立在兩個(gè)組織的觀點(diǎn)基礎(chǔ)上的：
從組織的觀點(diǎn)來(lái)看，ratlc 使命是(1)為所有的 ibm rational 開(kāi)發(fā)建立一個(gè)完整的共同工作流程;(2)設(shè)計(jì)一個(gè)最適合使用 clearquest 技術(shù)的方案;(3)在發(fā)布之前提供產(chǎn)品的真實(shí)使用環(huán)境。
從操作的觀點(diǎn)來(lái)看, ratlc 使命是(1)為所有的 ibm rational 提供一個(gè)24 x 7的cm(或者產(chǎn)品變更請(qǐng)求跟蹤)系統(tǒng);(2)在客戶使用之前找出我們軟件的問(wèn)題;(3)利用他們所開(kāi)發(fā)的工具為 clearquest 開(kāi)發(fā)組織提供直接經(jīng)驗(yàn)。
ratlc 方案包含了這兩個(gè)方面。它配置為遍布全球的若干個(gè)數(shù)據(jù)庫(kù)鏡像，以便為開(kāi)發(fā)小組和涉眾提供一個(gè)分布式環(huán)境。方案的部署提供了一個(gè)關(guān)于 ibm rational clearquest 的開(kāi)發(fā)組織是如何利用 clearquest 來(lái)管理變更從而取得更大成功的可靠的操作案例。
整合客戶支持 -- retain ratlc bridge
象很多規(guī)模比較大的、分布式軟件開(kāi)發(fā)組織的案例一樣，為了不復(fù)制在理論上儲(chǔ)存在原本可以直接連接到變更管理系統(tǒng)的分離數(shù)據(jù)庫(kù)中的數(shù)據(jù)，對(duì)我們來(lái)說(shuō)就必需利用其它的應(yīng)用軟件來(lái)對(duì) ibm rational 進(jìn)行整合。
尤為特別地是，ibm rational 支持組織利用一個(gè)叫做retain(遠(yuǎn)程技術(shù)援助信息網(wǎng)絡(luò))的呼叫中心(呼叫中心)應(yīng)用軟件來(lái)進(jìn)行記錄和跟蹤客戶問(wèn)題。技術(shù)支持人員和ibm客戶都是用這個(gè)系統(tǒng)來(lái)查看和跟蹤產(chǎn)品問(wèn)題的。在這個(gè)系統(tǒng)中，每個(gè)具體的問(wèn)題報(bào)告涉及一個(gè)特定的產(chǎn)品和發(fā)布版本，并有唯一問(wèn)題管理記錄(pmr)號(hào)的相關(guān)授權(quán)項(xiàng)目分析報(bào)告(authorized program analysis report (apar))。
pmr 和 apar 是存儲(chǔ)在 與 clearquest 變更管理系統(tǒng)分離的存儲(chǔ)庫(kù)中的。因此，當(dāng)時(shí)沒(méi)有直接的方法來(lái)確保這些客戶的請(qǐng)求或者問(wèn)題能夠在開(kāi)發(fā)小組的 clearquest 系統(tǒng)中被記錄并作為變更需求。最終的結(jié)果就是支持組和開(kāi)發(fā)組之間的分離。
開(kāi)發(fā)組和支持組都需要一個(gè)集成的系統(tǒng)，以使輸入到 retain 的數(shù)據(jù)就會(huì)轉(zhuǎn)移到 clearquest 的相應(yīng)字段，反之亦然。比如，一在呼叫中心應(yīng)用軟件中創(chuàng)建了一個(gè)客戶請(qǐng)求，而一個(gè)具有相同數(shù)據(jù)的 clearquest 變更請(qǐng)求應(yīng)該會(huì)自動(dòng)地從呼叫中心用戶請(qǐng)求傳遞過(guò)來(lái)。此外，當(dāng) clearquest 變更請(qǐng)求被解決了，相應(yīng)的呼叫中心信息就應(yīng)該被自動(dòng)更新。
名為 retain ratlc bridge 的集成系統(tǒng)可以滿足這些需求。這個(gè)系統(tǒng)能夠利用現(xiàn)有的變更請(qǐng)求跟蹤系統(tǒng)使開(kāi)發(fā)者和支持人員以及客戶進(jìn)行溝通。有了這種集成，支持人員和開(kāi)發(fā)者之間的信息流就能自動(dòng)形成并且是雙向的。支持人員可以在呼叫中心應(yīng)用軟件中記錄客戶的請(qǐng)求，這個(gè)請(qǐng)求可以觸發(fā)一個(gè)新的ratic變更請(qǐng)求的提交。類似地，開(kāi)發(fā)者也可以解決一個(gè)apar關(guān)聯(lián)的變更請(qǐng)求，這個(gè)apar可以直接在clearquest記錄中更新呼叫中心信息。
作為集成的一部分，在ratlc方案中，一個(gè)變更請(qǐng)求包括一個(gè)客戶信息表和一個(gè)apar信息表。一些填入到apar表中字段的信息將會(huì)被客戶通過(guò)呼叫中心應(yīng)用軟件查看到。
圖1描述了確保問(wèn)題解決的角色，同時(shí)還顯示了 retain ratlc bridge 自動(dòng)操作的過(guò)程。
圖 1: 自動(dòng)化客戶變更請(qǐng)求跟蹤的流程
如圖1所示：
一旦這個(gè)呼叫中心記錄被解決，一個(gè)觸發(fā)器就會(huì)通知這個(gè)客戶什么時(shí)候可以得到他的問(wèn)題的解決方案。有了這個(gè)集成，ibm rational 能夠?qū)蛻舻膯?wèn)題或者請(qǐng)求提供更快速、更高效的解決。同時(shí) retain ratlc bridge 還能夠改進(jìn)組織的目標(biāo)--更高效的客戶解決過(guò)程，并使客戶、支持人員和開(kāi)發(fā)者之間有更緊密的溝通。
客戶變更請(qǐng)求的解決
在這個(gè)部分中我將闡述 clearquest 開(kāi)發(fā)組織是如何利用它自己的產(chǎn)品來(lái)解決客戶變更請(qǐng)求的。
開(kāi)發(fā)人員和涉眾被列為小組的成員，這些小組成員按照特定的產(chǎn)品或組件被指定為變更請(qǐng)求的默認(rèn)開(kāi)發(fā)(dev)、測(cè)試(qe)，以及文件(doc)所有者。有了 clearquest 郵件通知，涉眾能夠接受到變更請(qǐng)求郵件，這些請(qǐng)求與他們相關(guān)，因此他們需要對(duì)這些變更請(qǐng)求進(jìn)行評(píng)估。
有了retain ratlc bridge，一個(gè)新客戶變更請(qǐng)求提交到這個(gè) retain 呼叫中心應(yīng)用軟件，就會(huì)觸發(fā)一個(gè)新的 clearquest 客戶請(qǐng)求，并產(chǎn)生一個(gè)apar編號(hào)，從而涉眾就會(huì)接受到對(duì)客戶請(qǐng)求的自動(dòng)郵件通知。這種自動(dòng)操作縮短了客戶、支持人員、開(kāi)發(fā)人員以及管理人員之間的間隔，并且改善了通信實(shí)效。
下面就是這個(gè)場(chǎng)景：
一旦這個(gè)變更請(qǐng)求解決，retain ratlc bridge 就可以確保呼叫中心應(yīng)用軟件中的信息被更新，這樣支持人員和客戶都能夠看到變更請(qǐng)求的狀態(tài)。需要注意的是集成還能夠進(jìn)行相反的工作流程，也就是支持人員也可以提交一個(gè) ratlc cr，然后自動(dòng)產(chǎn)生 retain 呼叫中心記錄(或者apar)。
要記住十分重要的一點(diǎn)是，一個(gè)變更請(qǐng)求可以由內(nèi)部客戶或者外部客戶來(lái)提交，也就是說(shuō)，這個(gè)變更請(qǐng)求來(lái)自創(chuàng)建這個(gè)產(chǎn)品的組織內(nèi)部的客戶，或者來(lái)自購(gòu)買這個(gè)產(chǎn)品的客戶。更進(jìn)一步說(shuō)，一個(gè)變更請(qǐng)求可以是一個(gè)缺陷或者一個(gè)改進(jìn)請(qǐng)求(rfe),但是從工作流程的角度來(lái)看，無(wú)論哪一種情況都能夠用相同的方法進(jìn)行處理。
認(rèn)識(shí)到客戶和涉眾可能分布在世界各地的情況也是很有好處的，這樣 ibm rational clearquest multisite 解決方案還有一些潛在的利益，我將在下面部分更詳細(xì)地討論這一點(diǎn)。
|||
利用 clearquest multisite 支持一個(gè)分布式環(huán)境
由于 ibm rational 的客戶眾多，ibm rational 開(kāi)發(fā)團(tuán)隊(duì)需要一個(gè)支持分布式環(huán)境的變更管理也是十分正常的事。ibm rational clearquest multisite 提供了一個(gè)解決方案。針對(duì) ratlc 我們使用了這個(gè)方案，在這個(gè)方案中我們定義了數(shù)據(jù)庫(kù)鏡像(database replicas)和 主控權(quán)(mastership) 策略支持分布在世界各地的部署，支持以及測(cè)試組。
圖2描述了 ibm rational 利用 clearquest multisite 進(jìn)行的 ratlc 數(shù)據(jù)庫(kù)鏡像的內(nèi)部開(kāi)發(fā)。(數(shù)據(jù)庫(kù)鏡像的真實(shí)名稱在這個(gè)圖中已經(jīng)被更改。)
圖2.一個(gè) clearquest multisite 部署的樣例
這篇文章的目的不是要詳細(xì)闡述如何安裝和支持一個(gè)分布式 clearquest multisite 環(huán)境，我將談?wù)撘恍┤绾翁幚碇骺貦?quán)(mastership)問(wèn)題的基本思想以及樂(lè)觀鎖定(optimistic locking)。
clearquest multisite 主控權(quán)
clearquest multisite 主控權(quán)的功能就是確保一個(gè) clearquest 記錄只能夠同一時(shí)間在一個(gè)數(shù)據(jù)庫(kù)鏡像站點(diǎn)更新。一個(gè)登陸到站點(diǎn)的用戶如果沒(méi)有記錄的主控權(quán)，只能查看記錄信息，而不能夠?qū)λM(jìn)行修改。要想進(jìn)行記錄更新，用戶必須登陸到擁有主控權(quán)的站點(diǎn)。
考慮這樣一個(gè)場(chǎng)景，客戶在倫敦，支持代表在班加羅爾，開(kāi)發(fā)人員在羅利，測(cè)試人員在北京。如果這個(gè)變更請(qǐng)求的確認(rèn)發(fā)生在北京，這也是一個(gè)數(shù)據(jù)庫(kù)鏡像的地點(diǎn)，這個(gè)記錄所有者可能要從一個(gè)站點(diǎn)更換到另一個(gè)站點(diǎn)，比如這個(gè)記錄的狀況從活動(dòng)變更到解決以及修正需要確認(rèn)的情況。(注意：用戶可以登陸到任何一個(gè)鏡像中來(lái)讀取信息，但是必須登陸到一個(gè)擁有主控權(quán)的鏡像才能變更這個(gè)記錄。)
樂(lè)觀鎖定
當(dāng)兩個(gè)人要更新同一個(gè)記錄時(shí)，clearquest 就可以利用樂(lè)觀鎖定來(lái)處理這種情況。第一個(gè)保存記錄更新的人——并不是第一個(gè)為了更新而打開(kāi)記錄的人——會(huì)成功。其它的變更就不會(huì)被保存。因此，第二個(gè)試圖更新記錄的人將需要重新得到這個(gè)記錄并重新進(jìn)行他或者她的更新。
我可以推薦一個(gè)減少這些麻煩的技術(shù)，因?yàn)?ibm rational 內(nèi)部也使用它，就是利用一個(gè)叫作 record_script_alias 的 clearquest scripted action 類型創(chuàng)建一個(gè)記錄。這個(gè) action 在一個(gè)遠(yuǎn)程的或者同時(shí)正在進(jìn)行更新的記錄上執(zhí)行。它可以創(chuàng)建一個(gè)新的記錄并且在這個(gè)帶有 action 記錄 id 的新記錄上更新一個(gè)新的字段。clearquest 然后創(chuàng)建一個(gè)從這個(gè)新的記錄 id 到這個(gè) action 記錄的 反向引用(back-reference)，不管是否設(shè)置了主控權(quán)。這兩個(gè)記錄都是對(duì)方的相關(guān)擴(kuò)展——直接在當(dāng)前站點(diǎn)，接下來(lái)就鏡像到其他站點(diǎn)。這個(gè)反向引用確保相連接的記錄能夠合適地更新。也就是說(shuō)，當(dāng)您創(chuàng)建一個(gè)記錄并更新涉及的字段時(shí)，這個(gè)反向引用將會(huì)更新相關(guān)的記錄，不管主控權(quán)還是樂(lè)觀鎖的爭(zhēng)用。
這里還有一個(gè)更進(jìn)一步的提示：當(dāng)創(chuàng)建子記錄作為創(chuàng)建父記錄的副產(chǎn)品時(shí)，使用您創(chuàng)建的父記錄的 commit event 來(lái)創(chuàng)建這個(gè)子記錄。
所有權(quán)(ownership)的角色
由于鏡像的局限性，對(duì)于 clearquest 來(lái)說(shuō)不能實(shí)時(shí)地確定記錄是否在更多的站點(diǎn)被創(chuàng)建或者變更。因此，如果記錄在多個(gè)站點(diǎn)被創(chuàng)建并反向引用，對(duì)于用戶來(lái)說(shuō)是不可能在事前知道這些情況的。您可以通過(guò)分配所有權(quán)和確定最有可能執(zhí)行 action 的人(或者唯一的人員)來(lái)進(jìn)行限制。這樣就縮減了與記錄相關(guān)的冗余的過(guò)程，更有效地創(chuàng)建一個(gè)虛擬調(diào)度機(jī)制。
這個(gè)方法同時(shí)還簡(jiǎn)化了主控權(quán)和樂(lè)觀鎖爭(zhēng)用問(wèn)題的解決。就是說(shuō)，您即可以象上面所描述的一樣來(lái)創(chuàng)建一個(gè)記錄然后用反向引用連接記錄，也可以用所有者指派的隱含更新來(lái)構(gòu)建記錄。您不必同時(shí)使用兩種方法。
基于角色的用戶體驗(yàn)
為了設(shè)計(jì)、實(shí)現(xiàn)和管理變更管理系統(tǒng)，clearquest 產(chǎn)品支持基于角色的模型 。
為了我們的中心目的，同時(shí)也為了說(shuō)明 clearquest 文檔的目的，ibm rational 已經(jīng)確定了三個(gè)常見(jiàn)(實(shí)際上非常普遍)角色。大多數(shù)其它您可能確定的角色都是這三個(gè)中的具體實(shí)例：用戶、管理員，以及方案開(kāi)發(fā)者。
用戶角色覆蓋了所有 clearquest 客戶端可用的任務(wù)，這些任務(wù)用來(lái)在用戶數(shù)據(jù)庫(kù)中重新恢復(fù)、創(chuàng)建或者修改數(shù)據(jù)。普通用戶任務(wù)包括從一個(gè)用戶數(shù)據(jù)庫(kù)中獲取信息和對(duì)這些記錄進(jìn)行操作，提交變更請(qǐng)求、處理變更請(qǐng)求、修改記錄中的信息，以及運(yùn)行查詢。用戶可能是提交客戶請(qǐng)求的支持代表，也可能是一個(gè)開(kāi)發(fā)人員，質(zhì)量工程師，信息開(kāi)發(fā)人員，或者提交，分配，處理，解決，以及為一個(gè)產(chǎn)品特定發(fā)布版本進(jìn)行變更請(qǐng)求確認(rèn)的管理者。
管理員的角色用來(lái)對(duì)數(shù)據(jù)庫(kù)、用戶，小組進(jìn)行管理，同時(shí)還包括安全策略的管理。一個(gè)管理員的常見(jiàn)任務(wù)包括配置和維護(hù)數(shù)據(jù)庫(kù)、管理用戶帳號(hào)，以及設(shè)置輕量級(jí)目錄訪問(wèn)協(xié)議(ldap)的授權(quán)。
方案開(kāi)發(fā)者的角色包括大多數(shù) clearquest designer 中用建立方案的功能，這些方案將定義用戶在 clearquest 程序用戶界面工作的數(shù)據(jù)庫(kù)。一個(gè)被執(zhí)行的常見(jiàn)任務(wù)包含所有的方案設(shè)計(jì)以及開(kāi)發(fā)，包括開(kāi)發(fā)狀態(tài)轉(zhuǎn)變模型、記錄、字段和動(dòng)作類型，以及每個(gè)記錄類型、字段和動(dòng)作的行為，包括鉤子(hook) 和腳本，同時(shí)還為 clearquest 客戶端的用戶開(kāi)發(fā)窗體。
在許多變更管理的實(shí)現(xiàn)中，可能只有少數(shù)的方案開(kāi)發(fā)人員和管理員，但是卻有相當(dāng)多客戶端程序的用戶——可能有幾千的用戶。在 ibm rational 內(nèi)部開(kāi)發(fā)小組中的確是這樣的，然而只有少數(shù)方案開(kāi)發(fā)人員和管理員對(duì) ratlc 方案進(jìn)行支持，并繼續(xù)進(jìn)行完善。事實(shí)上我們?cè)S多客戶的開(kāi)發(fā)團(tuán)隊(duì)也是這樣的。
然而，這些角色之間的界限是模糊的。比如，同一個(gè)人經(jīng)常會(huì)同時(shí)擔(dān)任著管理員和方案開(kāi)發(fā)者的雙重角色。類似地，鉤子的編寫者或者窗體的設(shè)計(jì)者也可能是安全策略的設(shè)計(jì)者或者管理用戶組和許可(也叫做用戶權(quán)限)的管理員。在 ibm rational 也有這樣的情況，可能有些用戶有管理員權(quán)限可以創(chuàng)建查詢并將它們保存到公共文件夾中，另外他們能夠管理一些數(shù)據(jù)庫(kù)，或者副本，或者用戶和團(tuán)隊(duì)。
內(nèi)部和外部的用戶
在許多cm實(shí)現(xiàn)中，給定的角色可能要分配給內(nèi)部和/或者外部的用戶。對(duì)于各種不同的用戶，像這樣的角色從補(bǔ)充用例文檔中受益是非常有可能的。
ibm rational 內(nèi)部的一個(gè)用戶，屬于 ibm 軟件小組或者 ibm 內(nèi)部的任何人，這些人可能在產(chǎn)品開(kāi)發(fā)部門工作，創(chuàng)建新的用戶界面，對(duì) clearquest 產(chǎn)品或者組件進(jìn)行集成工作，或者依靠 clearquest 核心功能或者服務(wù)進(jìn)行軟件應(yīng)用的工作。維護(hù) ibm rational 的 ratlc 的開(kāi)發(fā)人員他們本身就是 clearquest 方案 開(kāi)發(fā)和管理人員角色文檔的內(nèi)部用戶，作為其它地區(qū)的開(kāi)發(fā)人員他們利用 ratlc 數(shù)據(jù)副本為 clearquest 的功能開(kāi)發(fā)新的或者增強(qiáng)用戶界面，或者進(jìn)行測(cè)試產(chǎn)品的工作。對(duì)于 ibm rational 的現(xiàn)場(chǎng)代表也是這樣的，他們支持一個(gè)客戶變更管理解決方案并需要方案開(kāi)發(fā)的信息，或者一個(gè)客戶支持代表可能會(huì)在用戶管理部門回答一個(gè)客戶的問(wèn)題或者爭(zhēng)論。一個(gè)新的雇員需要通過(guò)用戶角色文檔學(xué)習(xí)如何使用 clearquest 并成為一個(gè)很好的內(nèi)部用戶。
外部用戶包括擁有自己的方案開(kāi)發(fā)人員、管理人員的客戶，或者合作伙伴，或者能為客戶創(chuàng)建解決方案的獨(dú)立軟件開(kāi)發(fā)商(isv)。方案開(kāi)發(fā)人員角色文檔的目的是支持那些服務(wù)提供者或者技術(shù)專家，他們?yōu)榭蛻糸_(kāi)發(fā)方案，在有些情況下應(yīng)用于一個(gè)內(nèi)部小組，比如為他們的組織運(yùn)行這個(gè)變更管理系統(tǒng)的內(nèi)部全體it小組。在有些情況下，對(duì)于規(guī)模大且高度自定義的配置，客戶會(huì)為他們的客戶端應(yīng)用程序的用戶文檔創(chuàng)建一個(gè)附加層，這個(gè)應(yīng)用程序可以提供一些詳細(xì)信息，即不但可以用通用方式使用 clearquest，還可以進(jìn)行一些特殊的實(shí)現(xiàn)。比如，產(chǎn)品本身能夠提供關(guān)于創(chuàng)建和運(yùn)行查詢的信息，但是作為一個(gè)客戶可能會(huì)對(duì)工作時(shí)的特殊查詢創(chuàng)建更詳細(xì)的文檔，這個(gè)查詢適用于特別的記錄類型、字段、狀態(tài)，或者在他們特定方案中定義的行為。
使角色更加具體化
從 ibm rational clearquest 7.0.0 版本中開(kāi)始，文檔就是基于角色的，以便用來(lái)增加用戶對(duì)每一個(gè)角色的體驗(yàn)。文檔中定義的用戶、管理員，以及方案開(kāi)發(fā)人員的角色對(duì)于大多數(shù)行業(yè)--如果不是所有的--的cm系統(tǒng)是十分有用的。
但是cm系統(tǒng)中的這些通用角色是與行業(yè)無(wú)關(guān)的，在一個(gè)方案中定義的記錄類型，及其狀態(tài)和行為(狀態(tài)轉(zhuǎn)變模型)與安全的定義級(jí)別一樣，都是高度自定義的，并可以用于多種行業(yè)和組織中——像角色本身一樣。雖然用戶的角色可能通用性的描述，但是它并沒(méi)有詳細(xì)地闡述具體的工作，比如數(shù)據(jù)輸入人員、銀行出納員、貸款人員，或者客戶支持代表。
例如，在 ibm rational 軟件開(kāi)發(fā)組織中，一個(gè)用戶角色的定義包括所有世界各地 ratlc 數(shù)據(jù)庫(kù)鏡像的用戶。用戶包括開(kāi)發(fā)人員、測(cè)試人員、技術(shù)專家、產(chǎn)品和項(xiàng)目經(jīng)理、處理客戶解決方案的現(xiàn)場(chǎng)代表，核查正在進(jìn)行的變更并且根據(jù)客戶需求提交變更請(qǐng)求的客戶支持代表，有時(shí)還包括合作伙伴或者那些能夠有限制地訪問(wèn)變更管理系統(tǒng)信息的用戶。
一些 cm 系統(tǒng)不但可以從不同角色的“個(gè)性化”用例中獲得利益，同樣可以從 clearquest 方案中的更專業(yè)化的角色中獲得利益。
新聞熱點(diǎn)
疑難解答
圖片精選
