使用GQM實現(xiàn)治理目標(biāo)

1、使用GQM實現(xiàn)治理目標(biāo)Roger Dunn, CEO, SourceIQ, Inc.Roger N. Dunn 是 SourceIQ 公司(一個致力于交付來自于 IBM Rational 基 礎(chǔ)架構(gòu)的管理標(biāo)準(zhǔn)的高級 IBM 商業(yè)伙伴)的創(chuàng)立者和 CEO。他擁有二十五 年的領(lǐng)導(dǎo)團隊進行 ISV 和 IT 軟件開發(fā)項目的經(jīng)驗。簡介： 閱讀目標(biāo)問題矩陣方法 ( Goal-Question-Metric Approach，GQM)如 何提供一種方法，這種方法對于整個團隊，或者個體的團隊成員來說，使他 們更好的理解他們在成功的軟件開發(fā)中所扮演的角色。 本文來自于 The Rational Edge 。標(biāo)

2、記本文！發(fā)布日期： 2008 年 4 月 15 日級別： 初級其他語言版本： 英文訪問情況 186 次瀏覽建議:中國有句古老的諺語，“千里之行始于足下” 。 1 當(dāng)在軟件項目規(guī)劃中起航 時，我不想在第一步就遇到絆腳石。我想要項目規(guī)劃能夠在控制之中并取得 成功，以避免另外一個著名的格言： “如果你不知道你要去哪里，那么你可 能會走向任何一條路。 ” 2問題矩陣方法( Goal-Question-Metric Approach ， GQM) 3 是一個強大的工 具，它能夠使您有信心和指導(dǎo)方向的邁出第一步。 GQM幫 助我們?yōu)楣芾砟Ｐ?建立框架，這是通過將最初的關(guān)注點放在我們想要實現(xiàn)的目標(biāo)矩陣上實現(xiàn)

3、 在本文中，我將從兩個方面展示 GQM。第一個方面是， GQM應(yīng) 用于什么我將 討論應(yīng)用 GQM 的四個階段：（1）建立目標(biāo)；（ 2）定義問題；（3）識別矩陣 ;（4） 設(shè)置行動模型 第二個方面是，我們能夠從已經(jīng)應(yīng)用了 GQM 的角色中學(xué)習(xí)到什么我將解釋 陣勢世界的 GQM 場景，針對于 IT 執(zhí)行管理層、項目經(jīng)理、架構(gòu)師、開發(fā) 經(jīng)理和軟件質(zhì)量經(jīng)理。我將通過再次的探索和調(diào)查得出結(jié)論， GQM如 何能夠更好的幫助我們定義我 們的第一步，以及后續(xù)的事情；它實際上如何能夠幫助扮演不同角色和不同 方面的知識工作者，以找到他們的共同點，使他們相互支持，以促進開發(fā)治 理和 IT 結(jié)果。應(yīng)用 GQM多數(shù)人知

4、道 GQM 是因為 Victor Basili博士的思想， Victor Basili 博士想為問題的解決和頭腦風(fēng)暴創(chuàng)建一個概念的框架。GQM 方法并不只限于軟件開發(fā)，或者 IT 治理，或者甚至是技術(shù)問題的解決，盡管它給了自己一個 非常好的技術(shù)環(huán)境?；旧?， GQM提 供了一個框架來幫助您理解您的目標(biāo)是 否已被實現(xiàn)。您可以提出您的目標(biāo)指令的問題，您可以建立驗證問題答案的 度量方法。 GQM是 靈活的，它被設(shè)計用來指導(dǎo)我們的認識上的潛力。 在本文中展示的 GQM 是基于幾年前 SourceIQ 所指導(dǎo)的過程成果相關(guān)涉眾 的訪談內(nèi)容的。這些 GQM 集合是典型的和有代表性的，但他們并不是完全 沒有

5、遺漏的。一旦您得到了基本的思想，您將能夠針對您的場景創(chuàng)建屬于您 自己的 GQM。 階段 1: 建立目標(biāo) 定義和澄清目標(biāo)是關(guān)于所需要的，因此使用目標(biāo)開始 GQM 是很自然的和直 接了當(dāng)?shù)娜蝿?wù)。它也是會給開發(fā)組織帶來切實的利益。目標(biāo)澄清方向，并展 現(xiàn)出企業(yè)將要走的路線，包括治理、質(zhì)量、會議計劃和預(yù)算，或者也包括客 戶滿意度。階段 2: 定義評估目標(biāo)進展的問題一旦我們在概念的層面定義了目標(biāo)， 之后我們將展示必須是可以回答的具有 操作性的問題，以確定進展或者目標(biāo)的實現(xiàn)。目標(biāo)和為目標(biāo)服務(wù)的問題典型地是我們在組織中所執(zhí)行地角色的功能。 也就 是說，他們是基于每個知識工作者類型的興趣和技能領(lǐng)域的。 當(dāng)不同角

6、色的人參與到 GQM 時，他們的目標(biāo)和問題第一眼看上去可能是不 相關(guān)的。例如， CIO 想要驅(qū)動創(chuàng)新，包括成本和業(yè)務(wù)單元之間的溝通。項目 經(jīng)理可能想改進對于未來新的和維護開發(fā)活動的估計。 QA 經(jīng)理可能關(guān)心特 定的目標(biāo)和與軟件質(zhì)量和過程穩(wěn)定性相關(guān)的問題。然而，當(dāng)我們進入到 GQM 的第三階段，我們也許會非常驚訝了解到哪些對 于開發(fā)治理表面上不相關(guān)的目標(biāo)，卻能夠在公用的度量模型中。階段 3: 識別支持回答問題的矩陣一旦您理解了需要評估目標(biāo)的問題， 之后我們將使用特定的必要矩陣來組織 問題的答案的方法建立度量模型。通過經(jīng)驗的觀察和與客戶一起工作的經(jīng)驗，我們發(fā)現(xiàn)對于不同的方面和視 角，為不同知識類型

7、的工作者建立的目標(biāo)和問題通常是不同的。一個典型的結(jié)果是 GQM 開發(fā)一個公共的理解，使用公共的度量模型，進 步這個模型直接連接到軟件開發(fā)的非常人性化的本質(zhì)： 我們的過程有多么融 合我們的項目復(fù)雜度如何有多少工作者能夠在新的復(fù)雜的有很多部分組成 的系統(tǒng)中能夠勝任軟件工作產(chǎn)品的質(zhì)量是否符合工程標(biāo)準(zhǔn)， 具有需要的生產(chǎn) 環(huán)境穩(wěn)定性階段 4: 設(shè)置行動度量模型一旦我們應(yīng)用了 GQM 并到達了支持我們需要的度量模型，我們就要準(zhǔn)備設(shè) 置行動模型了。在 " 軟件管理的開發(fā)治理 "中 4 , 我們討論過 IBM Rational 基礎(chǔ)架構(gòu)在應(yīng) 對遵循報告上自動化收集和軟件分析矩陣所扮演的角色

8、。 GQM幫 助我們將焦 點集中于我們需要實現(xiàn)的目標(biāo)上； Rational 為我們提供了交付這些矩陣的 平臺。換句話說，使用 GQM 決定您將度量什么，以及這些度量目標(biāo)實現(xiàn)程度的方 法。在您的 Rational 基礎(chǔ)架構(gòu)中將此方法應(yīng)用于您的開發(fā)過程的實際情 況，并且開始度量！通過角色應(yīng)用 GQMGQM通 常被認為是一個自上而下的方法， 它建議執(zhí)行管理層角色是我們的開 始點。但是驅(qū)動者，或者潛在的驅(qū)動者，對于變化來說通常以項目為中心。 這就意味著項目級的目標(biāo)是非常理想的 GQM 分析開始點。分析能夠向上擴 展到一個項目如何為公司的長期目標(biāo)服務(wù)， 或者向下擴展到項目如何影響個 體團隊成員的工作。我

9、將在本文的結(jié)論部分對它稍加解釋。實際上，自上而 下應(yīng)該可以很理想的符合由底至上的組織結(jié)構(gòu)， 這個方法將來自于執(zhí)行管理 層、適當(dāng)?shù)墓こ虡?biāo)準(zhǔn)以及來自開發(fā)和質(zhì)量保證層面的質(zhì)量標(biāo)準(zhǔn)轉(zhuǎn)化成了組織的目標(biāo)和質(zhì)量的命令我非常堅信 GQM 不應(yīng)該被認為僅僅是自上而下的框架，有時它被作為了這 個方法的限制。實際上， GQM不 僅僅能夠從組織的階梯結(jié)構(gòu)發(fā)起，它也能從 組織中的單一角色發(fā)起包括抵制使用 GQM 方法進行目標(biāo)分析的組織。也 就是說，它對組織中所有的角色不是強制性的，雖然所有的角色都使用這個 方法是理想的狀況。任何一個個體或者團隊都可以采用QGM ，無論他們是什么角色，即便其他人并不使用這個方法，您也將從

10、中受益。 注釋：一些團隊比其他團隊更需要 GQM。對于整體使用這個新方法的組織來 說，可以以最需要使用該方法的團隊為開始點，不要一下子全面鋪開，要逐 漸的向整個組織實施此方法。從上之下與從底至上融合的結(jié)果能夠帶來想法上的和諧， 或者導(dǎo)致列車的失 事；通常是在中間的某個地方結(jié)束。讓我們來了解一下GQM 與哪些開發(fā)組織中的不同角色有關(guān)。IT 執(zhí)行管理層IT 執(zhí)行管理層典型地是報告給一個業(yè)務(wù)部分的 CIO 。這個層面的目標(biāo)集中 于保持和吸引客戶的方法，在沒有犧牲基礎(chǔ)能力的前提下更具競爭力，并降 低成本的方法。這里由 4 個例子，它們在 SourceIQ 中是最典型的。G: 對客戶創(chuàng)新交付的增強。Q:

11、 我們需要對從軟件維護到新的開發(fā)的轉(zhuǎn)移進行資源與預(yù)算上重新分配嗎M: 生產(chǎn)環(huán)境的代碼量。 快速的增長或者膨脹的代碼導(dǎo)致了維護成本的急劇上升。 這將消耗更多的人 來處理現(xiàn)有應(yīng)用的問題解決和新特性開發(fā)。包含維護成本，并通過反向跟蹤在邏輯上產(chǎn)生的代碼增量。關(guān)系到了下面的架構(gòu)師的目標(biāo)M: 生產(chǎn)環(huán)境的代碼復(fù)雜度。 隨著時間的遷移，系統(tǒng)實現(xiàn)與復(fù)雜度將共存，因為修改問題和添加新功能將 會增加代碼量。執(zhí)行管理層在復(fù)雜度上的關(guān)注將影響團隊的行為，這可以通 過將改進的和可維護的代碼作為優(yōu)先級來實現(xiàn)。這將導(dǎo)致更低的TCO，并為創(chuàng)新節(jié)約了預(yù)算和人力。G: 通過改進交付和增加透明度，改進與業(yè)務(wù)部門的關(guān)系。Q: 我們?nèi)绾?/p>

12、能改進交付和增加透明度，以及與業(yè)務(wù)部門在目標(biāo)進展上的溝 通M: 生產(chǎn)環(huán)境的代碼量。通過溝通對于業(yè)務(wù)關(guān)鍵應(yīng)用的邏輯資產(chǎn)量， 這些資產(chǎn)的增長率和當(dāng)前的維護 和增強活動的關(guān)系， IT 將能夠通過實際的，基于現(xiàn)實的方法與客戶進行溝 通。業(yè)務(wù)部門將了解到 IT 部門對于他們業(yè)務(wù)擴展的工作支持和結(jié)果。 M: 軟件開發(fā)活動的揮發(fā)性支持業(yè)務(wù)邏輯的可視化將顯示出 IT 正在對業(yè)務(wù)部門的需求、 增強和維護工 作做著積極的響應(yīng)。G: 為更精確的預(yù)算預(yù)測獲得基線Q: 實際需要的工作如何能夠完成，將被評估的里程碑如何被應(yīng)用到未來的 工作中M: 軟件開發(fā)活動的量級和揮發(fā)性 與過去工作相關(guān)聯(lián)的度量量級和揮發(fā)性形成了未來類似

13、實現(xiàn)規(guī)模的基線。 假 設(shè)對于開發(fā)人力的技能集和領(lǐng)域?qū)＜冶３窒鄬Ψ€(wěn)定， 應(yīng)用在上的技術(shù)也沒有 巨大的變化， 包含在您的軟件配置管理系統(tǒng)中的處理信息能夠被用來生成對 未來工作的清晰的一致的基線?；€的信息越多，管理層應(yīng)該也能看見根據(jù) 應(yīng)用生命周期管理上的基線的可度量的改進 （培訓(xùn)、測試自動化、 持續(xù)集成、 敏捷方法、降低需求誤解、動態(tài)語言的使用，等等。 ）G: 從開發(fā)的合作伙伴獲得高層的明確標(biāo)準(zhǔn) / 性能指標(biāo)Q: 我的合作伙伴如何滿足我的組織的標(biāo)準(zhǔn)呢對于其他的合作伙伴又如何呢M: 揮發(fā)性、復(fù)雜性、語言規(guī)則遵循、編碼指南。管理外部的開發(fā)需要面對 更大的挑戰(zhàn)。是否存在足夠的服務(wù)級別約定（ SLA）標(biāo)準(zhǔn)

14、呢工作活動是否符 合公司的標(biāo)準(zhǔn)（復(fù)雜度和其他規(guī)定） ，計劃的發(fā)布時間符合標(biāo)準(zhǔn)嗎是否存在 有效的技能移交對于項目或者任務(wù)的類型， 合作伙伴是否具備合格的能力使 用矩陣進行比較能夠驅(qū)動管理層與合作伙伴的關(guān)系，并驅(qū)動更好的交付。 項目經(jīng)理 典型的項目經(jīng)理面對從他的項目的日常細節(jié)被解放出來的問題。與此同時， 項目經(jīng)理為生成環(huán)境的質(zhì)量目標(biāo)，以及滿足眾多的計劃時間點為煩心。這些 關(guān)注被新引進的生產(chǎn)模式更加擴大化了，比如，敏捷開發(fā)方法與全球化分布 式團隊的結(jié)合這些顯示快速的導(dǎo)致了更加痛苦的場景。 項目經(jīng)理需要的是 一致的使用模型，團隊改進的模式，以及支持采用新目標(biāo)的度量模型。G: 確保穩(wěn)定性、可預(yù)測性的開發(fā)

15、過程來滿足計劃的里程碑。Q: 我的項目是否按照計劃的軌跡前進，計劃的里程碑都能實現(xiàn)嗎M: 軟件項目開發(fā)工作的揮發(fā)性（分支、流、統(tǒng)一變更管理（ UCM）活動）。 項目經(jīng)理的工作通過在項目的關(guān)鍵點上轉(zhuǎn)化的成果和效率被度量。在 IBMRational Unified Process （RUP） 中，項目經(jīng)理敏銳的觀察在精化向構(gòu)建轉(zhuǎn) 化中發(fā)生的事情；用更傳統(tǒng)的術(shù)語說，從設(shè)計到編碼階段。當(dāng)一個項目在計 劃的軌跡上時，項目開發(fā)活動的揮發(fā)性也在被度量，在項目計劃期間，這種 揮發(fā)性沿著計劃的路徑到達穩(wěn)定的發(fā)布點。如果項目背離了計劃，這種不一 致將會很容易被發(fā)現(xiàn)， 這將告訴項目經(jīng)理應(yīng)用航向修正來確保項目回到應(yīng)有

16、 的軌跡上。G: 維護適當(dāng)?shù)娜肆Ψ峙湟詽M足計劃的里程碑Q: 我的全球化團隊適合我的項目嗎這些團隊成員能夠高效的工作以實現(xiàn)項 目目標(biāo)嗎M: 軟件項目開發(fā)工作的揮發(fā)性（分支、流、統(tǒng)一變更管理（ UCM）活動）。 為了滿足項目的進度要求， 項目經(jīng)理必須維護開放和有效的在團隊成員之間 的溝通，理解合適人員需要進行調(diào)整。這在一個小的團隊可能是容易的，但 對于個全球化分布的團隊，就會比較難。項目經(jīng)理能夠根據(jù)SCM 系統(tǒng)評估每個個體、工作組的貢獻，并決定現(xiàn)在的人員分配和任務(wù)分配是否合理。這 種評估理想情況下是根據(jù)項目計劃和開發(fā)方法進行的 （輕量級還是重量級） 。G: 在項目完成時，交付到生產(chǎn)環(huán)境的代碼要滿足

17、組織的質(zhì)量目標(biāo)Q: 開發(fā)的每個階段的工作都符合這個目標(biāo)嗎M: 復(fù)雜度、語言規(guī)則遵循、編碼指南。通過監(jiān)控這些因素， 項目經(jīng)理能夠建立起在質(zhì)量經(jīng)理與項目經(jīng)理之間的更有 效的工作關(guān)系。這種關(guān)系在開發(fā)過程中識別上游的質(zhì)量問題是至關(guān)重要的。 這使得修改問題更加容易并且節(jié)省成本， 以至于項目的整體質(zhì)量符合生產(chǎn)環(huán) 境的質(zhì)量標(biāo)準(zhǔn)。架構(gòu)師 迭代開發(fā)方法典型地將架構(gòu)師作為項目的開發(fā)點， 輔助開發(fā)團隊完成需求階 段，并進行早期的少量編碼。切記，這不僅僅對您的項目是事實，所有通常 都是這樣的。對于架構(gòu)師的需要是跨項目的，這就意味著對你給您的軟對開 發(fā)編碼是，架構(gòu)師可能在其他項目的啟始階段中忙碌著。架構(gòu)師所需要的是 對

18、所有項目的一些可視化的級別，以確保對整體目標(biāo)的把握，以滿足公司級 別的目標(biāo)。如果每一個開發(fā)團隊都指定自己的方向， 那勢必將造成混亂局面。 G: 當(dāng)項目從精化階段向構(gòu)建階段過渡時，確保架構(gòu)構(gòu)建被適當(dāng)?shù)膽?yīng)用。 Q: 項目團隊的技術(shù)選擇滿足架構(gòu)目標(biāo)嗎（組件化、面向服務(wù)的體系架構(gòu) （SOA），框架，等等）M: 類型、復(fù)雜度的邏輯工作的量級 當(dāng)項目從精化（設(shè)計）階段過渡到構(gòu)建（編碼）階段時，架構(gòu)師就可以離開 這個項目了，通常是因為他們被調(diào)到了其他項目中，或者其他的原因是現(xiàn)在 是編碼團隊工作的時間了。為了生成更加健壯和可維護的系統(tǒng)，可能會發(fā)生 團隊從架構(gòu)原則中迷失了。 設(shè)計規(guī)則被忘記， 接口被破壞， 技術(shù)

19、被隨意使用。 通過檢測在開發(fā)中產(chǎn)生的邏輯工件的數(shù)量級， 架構(gòu)師能夠獲得深度和準(zhǔn)確的 并開發(fā)人員使用的開發(fā)模式的情況， 從而更好的控制和調(diào)整團隊回到正確的 道路上。復(fù)雜度也能夠生成對于設(shè)計和設(shè)計到代碼的轉(zhuǎn)換的效率的深度觀 察。G: 確保組織使用了適當(dāng)?shù)募夹g(shù)。 Q:什么樣的開發(fā)技術(shù)正在被使用開發(fā)的實際成果與計劃相符嗎M: 生產(chǎn)環(huán)境中按類型劃分的邏輯工件的量級和揮發(fā)性 公司采用他們認為最適合實現(xiàn)成功的在項的技術(shù)， 這些技術(shù)將確保項目能夠 在人員和預(yù)算的范圍內(nèi)交付成功的系統(tǒng)。通過檢測與生產(chǎn)系統(tǒng)的邏輯矩陣， 架構(gòu)師能夠決定是否應(yīng)該作出決策。例如，他也許想看看高端的開發(fā)方法產(chǎn) 生了大量的代碼， 需要很多高

20、級的開發(fā)專家， 并且需要而外的團隊進行維護。 通過參與基于實際情況的討論，架構(gòu)師能夠幫助指導(dǎo)組織根據(jù)目標(biāo)選擇技 術(shù)、動態(tài)語言、申明性語言、設(shè)計模式、框架和其他的構(gòu)建，以幫助團隊、 執(zhí)行管理層和經(jīng)理們實現(xiàn)他們的目標(biāo)。開發(fā)經(jīng)理 開發(fā)經(jīng)理，或者開發(fā)主管，是艱苦的工作。他們是有才能的，這意味著他們 工作時間更長。 我所見過的所有的開發(fā)經(jīng)理都表示出開發(fā)使開發(fā)團隊完成工 作的困難，同時他們需要管理由于在團隊中的高頻率加班所導(dǎo)致的組織級的 低效，在離岸團隊更是如此。經(jīng)驗缺乏的初級開發(fā)人員需要與高級的開發(fā)人 員配對工作來產(chǎn)生最大化的生產(chǎn)力。因為初級的團隊成員的進步，開發(fā)經(jīng)理 有更多的時間來改進他們負責(zé)的代碼。

21、G: 最大化所有團隊貢獻者的生產(chǎn)力。Q: 開發(fā)人員能夠完成分配給他們的任務(wù)嗎，或者他們遇到障礙了嗎M: 由個體或者工作組產(chǎn)生的項目工件的量級 開發(fā)經(jīng)理的一個最大的挑戰(zhàn)是幫助開發(fā)人員克服障礙。 當(dāng)人們在工作中遇到 問題時，他們通常絕口不提，這通常是人的本性。當(dāng)然多數(shù)的開發(fā)人員不想 讓開發(fā)經(jīng)理覺得他不能夠完成分配的任務(wù)。有時因為任務(wù)分配的不合理，開 發(fā)人員也會延遲交付。無論是什么原因?qū)е碌?，很多人為的傾向?qū)绊戦_ 發(fā)人員的生產(chǎn)力，并影響項目的成功。開發(fā)經(jīng)理能夠監(jiān)控與任務(wù)分配和方法 相關(guān)的開發(fā)人員的貢獻在候補區(qū)，或者不同的地方。當(dāng)開發(fā)人員在一個任務(wù)上遇到困難時，開發(fā)經(jīng)理以積極和有建設(shè)性的方式進行干

22、預(yù)，并幫助開發(fā) 人員克服困難。G: 為初級的開發(fā)人員建立導(dǎo)師機制Q: 哪些開發(fā)人員需要在什么領(lǐng)域的幫助M: 復(fù)雜度、語言規(guī)則、編碼指南 開發(fā)經(jīng)理負責(zé)幫助初級開發(fā)人員找到資深的高級開發(fā)人員作為他的導(dǎo)師。 通 過檢測初級開發(fā)人員根據(jù)組織標(biāo)準(zhǔn)的工作，開發(fā)經(jīng)理能夠知道誰需要導(dǎo)師， 需要哪方面的導(dǎo)師。 開發(fā)經(jīng)理可以將有經(jīng)驗的高級開發(fā)人員與初級的開發(fā)人 員進行配對工作，讓初級開發(fā)人員學(xué)到更多的經(jīng)驗。G: 通過對高風(fēng)險的代碼進行同行審查降低實現(xiàn)風(fēng)險Q: 什么樣的模塊最可能包含錯誤，尤其是那些在測試中難以發(fā)現(xiàn)的錯誤， 或者最難理解和維護的錯誤M: 復(fù)雜度、語言規(guī)則、編碼指南 同行審查是一個共享實現(xiàn)知識的強大的

23、工具， 它能夠使系統(tǒng)代碼更加強壯和 可維護。因為系統(tǒng)在范圍和規(guī)模上不斷的增長，這使得模塊的審查也變得日 益困難。矩陣能夠查明這些模塊： (a) 測試沒有覆蓋到的模塊， (b) 容易出 錯的模塊， (c) 語言提供商導(dǎo)致的失敗執(zhí)行的模塊， (d) 花費大量時間去維 護的模塊。軟件質(zhì)量經(jīng)理經(jīng)過證明， GQA方 法帶來的一個好處是面向質(zhì)量保證( QA)團隊的。作為軟 件開發(fā)生命周期中其他角色的伙伴，提高 QA 的效率， GQM將 度量模型的權(quán) 利放在了 QA 的手上。 GQM能 夠幫助質(zhì)量成為每一個開發(fā)階段的部分，不僅 僅是在開發(fā)的末期。 QA 人員理解這個，但開發(fā)人員和架構(gòu)師通常不理解。 基于 G

24、QM 的問題和答案能夠引入新的構(gòu)建以支持質(zhì)量目標(biāo)，帶來更少的缺 陷和更加流暢的開發(fā)過程。G: 為 QA 報告維護一致的基線。Q: 給定的發(fā)布有多大（輸入以計算缺陷密度）M: 量級。 更有見識的 QA 能夠看出一個發(fā)布的規(guī)模，這將使缺陷密度變更更加有 用。規(guī)模典型地用代碼行（ LOC）表示；考慮使用代碼行，因為代碼行矩陣 能夠最好地表達真實地邏輯量級。當(dāng)使用代碼行時，重要地是僅僅計算實現(xiàn) 了邏輯那些工件。 對于不同的測試策略 （例如，Java 對比 JavaServer Pages （JSP） ），區(qū)別不同類型的工件是非常有用的。 其他的規(guī)模計算方法包括程序、 聲明和功能點數(shù)量。G: 改進 QA

25、 效率，并通過避免無保證的測試來節(jié)省成本Q: 當(dāng)前的開發(fā)與最初的測試一致嗎M: 揮發(fā)性 測試軟件是非常耗時和昂貴的，尤其是，當(dāng)軟件系統(tǒng)不斷的擴大，復(fù)雜度不 斷增加。揮發(fā)性幫助 QA 經(jīng)理理解是否一個發(fā)布對于一個適當(dāng)?shù)臏y試的點來 說是穩(wěn)定的。G: 在維護開發(fā)治理上成為開發(fā)的更有效的伙伴。Q: 提交用于測試的發(fā)布符合被建立的開發(fā)標(biāo)準(zhǔn)嗎M: 復(fù)雜度、語言規(guī)則、編碼指南QA 在實現(xiàn)開發(fā)治理中扮演了一個完整的角色。它是一個發(fā)布是否符合開發(fā) 標(biāo)準(zhǔn)的最后一關(guān)。 QA 在開發(fā)上的責(zé)任非常清楚，就是要將質(zhì)量構(gòu)建到軟件 系統(tǒng)中。通過應(yīng)用根據(jù)開發(fā)標(biāo)準(zhǔn)的“可信的，卻又驗證”模型， QA 能夠?qū)?現(xiàn)有價值和適當(dāng)審計的功

26、能。結(jié)論GQM可 以作為無價的助手來幫助您在軟件矩陣程序中邁出第一步。 無論對于 治理、軟件質(zhì)量，或者過程改進，基于目標(biāo)定義矩陣程序?qū)⒋_保您工作的價 值，并使您邁出萬里長征的第一步。 讓我們通過澄清兩個關(guān)鍵問題來結(jié)束本文。 GQM真 的使自上而下的嗎核心矩 陣定義真的是自底向上的嗎當(dāng)公司盡力采用新事物時， 通常都存在一定程度 在組織級別上的抵觸。我們不想變更。如果他們認為一些新的自上而下的管 理模式被強制的推行到他們，一些人感到不安，甚至是驚訝。 Basili 使用 GQM的 方法是授權(quán)個體和他們的同事，無論他們在組織的高層、底層或者中 層。我們所有人都有與我們的角色相關(guān)的目標(biāo)。 了解過程和其他角色的目標(biāo)將使 我們從其他角色中學(xué)習(xí)到很多通用的東西。15 年前，Jeff Alger 發(fā)布了一個有用的分類， 被稱為“中心、外圍和校準(zhǔn)”。 其思想使通過關(guān)注熟悉的事情開始，然后從舒適區(qū)走出來，探索新的想法和 概念，并且最終重新校準(zhǔn)他們的觀點。迭代之上的迭代導(dǎo)致了世界視角的擴 展。使用 GQM，我們基于我們的角色，或者中心，定義了目標(biāo)。我們每個人都基 于我們的中心表達目標(biāo)。例如，開始時，我們也許分離的看待我們的目標(biāo)， 而不是從一個大的整體視角，就像圖 1 顯示的。圖 1: 首先，團隊角色是彼此孤立的當(dāng) GQM 實踐的進展，我們也了解到了其他的組織目標(biāo)。更加理解外圍的問 題，