有效的用例編寫規則(2)

　　2.2 ParticipatingAudience

　　沒有涉眾提供的信息和反饋，就不能滿足他們的需要;盡可能使客戶和內部涉眾積極參與用例開發過程。

　　2.3 BalancedTeam

　　由一些個性相似、意見相同的個人組成的團隊開發用例，可能會得到一組缺乏創見、范圍狹窄的用例，這種用例不能滿足每個人的需要。

　　因此，為小組配備具有不同專長的人員，以維護開發過程中涉眾的利益，確保團隊中包括開發人員和最終用戶。

　　最大好處是使編寫人員在用例中使用常見的、可理解的術語。

　　第三章 過程

　　編寫好的用例是極其個性化的，每個人都有他自己的風格，每個組織都有根據自己的文化和業務需要做事情的方式，因此，沒有創建用例的通用過程。

　　3.1 BreadthBeforeDepth

　　原因：

　　需求收集是一個發現過程，用例編寫是一個迭代過程;

　　人們很早就開始編寫用例的細節;

　　人們浪費了精力或陷入了太多的細節，通常都會失去重點，無法描述所有可能的擴展條件;

　　從早期獲得概述是有益的;

　　最初編寫的細節越多，在了解系統后必須進行的改變也就越多;

　　所以：

　　通過首先開發用例的概述來保存精力，然后逐步增加細節，并行開發一組相關用例。

　　完成概述用例后，隨著對系統了解的增多，不斷提高用例精度，避免突然開發完所有用例或一次只開發一個用例的傾向。

　　3.2 SpiralDevelopment(螺旋式開發)

　　原因：

　　理解系統的行為可能會花掉大量時間，要求漸進式分析;

　　拖延是昂貴的。要盡快完成用例的編寫;

　　對需求進行分析后，需求很可能會發生變化;

　　需求成本的錯誤是昂貴的;

　　所以：

　　以一種迭代的，寬度優先的方式開發用例，每次迭代都會提高用例集的準確性和精度。

　　基本過程：

　　從簡單的東西開始，如一個參與者/用例列表;

　　簡要描述用力主場景，即高層用例，以包含用例的主要范圍;

　　擴展摘要的子集，并填充細節;

　　評審并調整;

　　3.3 MultipleForms

　　不同的項目需要不同程度的形式化，每個人對模板都有不同的偏好，要求每個人都使用相同的用例模板只會起到相反的作用。

　　原因：

　　每個人的個性、經驗和經受的鍛煉不同，每個開發組織都有其特有的人員、歷史和文化;

　　不同的項目有不同的需要;

　　不同的編寫團隊需要不同程度的規范和嚴格度;

　　在組織中使用公共的編寫形式有助于交流;

　　在同一個項目上使用不同的模板不是一個好主意;

　　因此：根據項目相關的風險性、項目特點，和所涉及到的人員選擇用例的編寫格式，并在該項目的開發過程中的組織內部使用。

　　3.4 TowTireReview(評審)

　　許多人都可能需要評審用例，這是一件昂貴耗時的事情。

　　原因：

　　對于驗證和確認編寫及內容來說，評審是必要的;

　　涉眾在用例上有一種既得利益;

　　使每個人參與編寫過程非常昂貴、麻煩并且緩慢;

　　如果僅由一個小的編寫組進行評審，就不會考慮所有涉眾的利益;

　　評審可能是昂貴的、乏味的、耗時的。

　　所以：

　　進行兩種類型的評審：第一種是由較小的內部小組進行的評審，可能要重復進行很多次;第二種是由整個團隊進行的評審，可能只進行一次。

　　3.5 QuittingTime

　　開發一個超出了涉眾和開發人員需要的用例模型不僅浪費資源，而且會拖延項目進度。

　　原因：

　　忽視重要需求的巨大恐懼使構建人員和涉眾延長了需求收集活動;

　　大多數人可以用一種合理的模糊性工作，即不言自明;

　　詳細講述謊言并不能使他們更為精確;

　　所以：

　　在用例完整并且符合參與者的需要后，停止開發用例;

　　用例模型完整性的檢驗：完整、可讀、邏輯上正確、對開發人員足夠詳細。

　　是否識別了所有的參與者和目標并將其編成了文檔?

　　客戶及其代表是否承認用例集是完整的，而且每個用例都是可讀的和正確的?

原文轉自：http://www.uml.org.cn/Test/200705175.asp