l

2012年2月4日 星期六

Quality Attribute Scenarios(2):會不會太理論了一點?

February 02 09:16~10:33

有讀過「Quality Attribute Scenarios(1):簡介」的鄉民們不曉得是否有一個疑問:「這個方法真的可以在業界被使用嗎,會不會太理論了一些?」其實Quality Attribute Scenarios(QAS)的目的就是以撰寫劇本(scenario)的方式來具體化原本很抽象的非功能需求,這一點其實跟agile methods採用stories來描述(功能)需求的精神是很類似的。幫鄉民們複習一下,為什麼agile methods要建議用stories來描述需求而非使用use cases?

  • 一個story可以想像成是一個use case的某條執行路徑,也就是說一個use case是某個功能(需求)的一般性(較抽象)的敘述。
  • 敏捷方法要求團隊要在較短的週期(2-4周)釋出軟體,如果用use case來描述需求可能會無法在一次開發週期中完成這個use case,因此就把需求寫成更小且更具體的story。
  • 假設一個use case被切成四個stories,每個sprint完成兩個stories,那麼經過兩個sprints之後原本可能有點抽象的一個use case就完成了。因此Teddy會覺得story比use case更容易「操作(operational)」。需求的可操作性是一個很重要的特性,如果需求寫得太抽象,那敏捷開發團隊很難在短時間內完成該需求。

套用相同的精神,如果在描述非功能需求時只是說「這個系統需要具備高可用性(high availability)」,這樣的非功能需求對於任何的開發團隊而言都是很難施工的(non-operational)。所以如果把非功能需求寫成scenario(鄉民們可以把scenario和story想成同意字)那麼開發團隊就比較容施工與派工,對於客戶而言也可以根據所寫出來的QAS來驗收系統的非功能需求(不然要如何驗收一個系統是否滿足high availability?)。

就好像story有類似「As a user, I can do xxx so that I can yyy」這樣的固定格式,QAS所規定的六個元素(Source of stimulus、Stimulus、Environment、Artifact、Response、Response measure)也只是幫忙開發人員可以方便寫出QAS。雖然課本(Software Architecture in Practice, 2nd)的QAS是用畫圖的方式表示,但是真正在寫QAS的時候並不一定要畫類似下面的圖,可以用類似下列表格的形式來撰寫:

Quality Attribute Source of stimulus Stimulus Environment Artifact Response Response measure
Availability            
           
           
Robustness            

或是寫成story的形式,例如:

  • 圖(b):As a boundary component, when a callee throws an exception at runtime, I will transform the exception semantics according to the upper layer’s aspect so that the upper layer can has a meaningful context to handle the exception. 至於Response Measure可以寫在story的how to demo這個欄位。
  • 圖(c):As a application controller, when a callee thorws an exception at runtime, I will perform state-recovery so that the system can continue to run. 同樣的,把Response Measure寫在story的how to demo欄位。

QAS-1

***

友藏內心獨白:搞軟體的人好像變來變去都是那幾招,只是試圖用不同的講法來包裝,還挺會搞行銷的。

沒有留言:

張貼留言