GQM Strategies

01 July 2020

Goal-Question Metric(GQM)

GQM也是一種測量軟體品質的metric，設定一些目標或question，看達成這些目標的程度來當成metrics

  1. 先設定measurement goal
  2. 設定evaluating goal結果的問題(回答這個evaluate值的好壞)，可以有複數個問題，也可以有subquestion，即qeustion或metrics其實都可以有多個layer/level。
  3. 設定回答question的metric，一個question也可以有多個metrics
  4. 蒐集到metrics的資料後就可以回答問題，就可以得到evaluation results

EX:

Goal refinement

設定goal可以依照下面的準則，會設定出更詳細、明確的goal

  1. Analyze:要檢驗的目標(ex: process,source code,資源)
  2. Purpose: 就是target(例如找low-maintainability code)
  3. Respect to: 造成上面問題的原因之類的，就根據這些原因來measure(例如code clone)
  4. View point: 從誰的角度
  5. Context: 這個goal的影響層面

Define good questions

設定direct question，接著設定關於goal的一些attribute的問題、從不同測試者(PM,tester…)的角度提出測量attribute的問題。

Extension of GQM model

新增一個hypothesis layer between goal and question
可以幫助設定question，所以設定一些假設可以幫助設定問題，更系統化。
幫助解釋為何要提出這個問題，或者為何要做某種測量(因為要驗證某個提出來的假設)

  1. seperate assumption from facts
  2. 先設定hyptohesis,再根據假設設定問題來驗證假設
  3. 利用統計或者assumption來設定測量的threshold，依情況在重新設計requirement重新測量

GQM-strategy Background

一整個產品會有很多參與者，每個參與者希望達到的目標不同 例如有PM/business level的人員，也有開發端、軟體端人員 他們所希望達到的目標可能有些許不同。 例如business level除了要增近產品quality外，還要增進usability 對於軟體開發者而言，他可能相對比較在意的像是第一點，或者maintenance，而business level就不在乎維護的問題

因此不同人在意的點不同，關注的metrics之類也不同，就彼此協調測量時就會容易有misalignment之類的。想improve的點不同，然後彼此可能又稍微有些關聯(例如一起improve或者一個會improve一個會下降)，造成不同level的目標的不協調。所以GQM Strategies幫忙釐清不同人員想達到的目標間的關聯(例如互相衝突、互相相關、相似)

此外也能避免產生多餘的或者跟其他問題無關的strategy或者data，或者補上漏掉的data,strategy。

GQM Structure

Organization goal設定GQM、問題，接著提出strategy來解決這些問題，對於每個問題可以再切更細成各個sub GQM問題。 就是一個樹狀結構，節點是goal,strategy這樣交替。 先提出一個目標，再提出一些達成這些目標的問題(如何達成這些目標)，再針對這些問題提出目標，遞迴下去。

Organizational Goal: 某層人員希望達到的目標(可以一起記錄這目標是以誰的viewpoint,focus的quality)
Strategy: 達到目標的方法、測量的metrics
Context: 描述現在狀況、擁有的資源，或者一些對於現有data的事實
Assumption: 假設一些statement(believed to be true but not evaluated)，context和assumption會決定strategy和goal
GQM Graph: goal + question + metric, 一個GQM Graph至少要測量一個organization goal

流程

基本上就是上圖這樣的模式，決定目前app的目標，依照現有的資源設定好欲達成的目標並制定strategy、organize data, feedback機制，接著implement，依照feedback、結果再revise現有的strategy/ context / assumptions，並記錄這次的progress跟紀錄。

Example

我們可以把整個圖畫成這樣，基於結果來衡量終極目標有沒有達成。如果沒達成則是可以知道是哪個環節出問題

Pros and Cons

Advantages

  1. 能夠幫忙釐清產品的方向跟所有需要做到的目標
  2. 能夠有系統的統整不同部門對於產品的看法與期望，並能藉此看出不同部門間目標的衝突之類的，並在早期就做好修改
  3. 能夠持續追蹤產品完成度(看完成多少的organization goal)

Disadvantages

  1. 要花非常多的人力、時間來維持這個GQM strategy，因為產品方向可能不斷有改變，細部goal, measurement方式也很常會變，因此要花時間來保持GQM圖永遠符合現在最新的狀況，如果沒更新好很容易發生錯亂或者誤導的資訊。
  2. 蠻不適合agile的，因為agile就是先做再說，GQM感覺比較適合waterfall開發模式

HoRIM: 找到彼此strategy的關係，能夠得知哪些strategy是相似或有衝突的，可以協助revise GQM