基于用例点来度量软件规模并管理进度 之一
英文名：Based?on?use?case?points?to?measure?software?size?and?manage?the?progress
摘 要?
本文針對軟件項目的規(guī)模度量和進度管理，提出了一種新的以用例點的方式來表達和跟蹤的方法。本文詳細介紹了經過調整過的用例點度量方法，舍棄了角色對應的用例點數(shù)，對用例分類給出了更嚴格的要求，采用了更細致的步驟定義，并限制了復雜用例的最多步驟。用例的狀態(tài)完成度得到區(qū)分，在此基礎上建立了過程中用例的進度跟蹤方法。最后并闡述了在需求可復用情況下的使用方式。
關鍵詞?
用例點?軟件規(guī)模?進度?度量
Abstract?This?paper?purposed?a?new?method?of?measuring?software?size?and?tracking?progress?for?size?and?progress?management?of?software?project.?The?detail?of?use?case?points?counting?is?illustrated,?Use?Case?Points??of?the?roles?are?abandoned,?Classification?of?use?cases?are?given?more?stringent?requirements,??a?more?detailed?definition?of?the?step?is?used,??and?the?maximum?of?steps?in?the?complex?use?cases?is?limited.?Completion?degree?of?the?state?of?use?case?is?distinguished,?and?based?on?this?the?method?of?tracking?progress?of?ongoing?use?cases?is?setup.?And?further?usage?in?re-use?requirements?is?also?covered.
Keywords?Use?Case?Point,?Software?size,?progress,?measure
引言
軟件規(guī)模度量方面，存在了不少難題：
1，開發(fā)語言發(fā)展快，最新的IDE能夠自動生成大量代碼
2，維護升級項目的規(guī)模難于估算
3，軟件復用后的規(guī)模難于估算
4，不同軟件項目的規(guī)模相關的比較
傳統(tǒng)軟件規(guī)模度量采用源代碼行數(shù)，但源代碼行數(shù)有明顯的缺點。因此當前在軟件行業(yè)，發(fā)展出了多種軟件項目規(guī)模的度量方法，較有代表性的如下幾種：
Function?Points?縮寫FP
Use?Case?Points?縮寫UCP
User?Story?Points?
本文根據(jù)實踐，參照原UCP方法[參考文獻1]，介紹了一種新的以用例點為單位的軟件規(guī)模表達方法，并利用這個方法表達軟件開發(fā)過程中的進度，對上述的問題進行了處理。
用例點表達規(guī)模
第一步?計算UCP
首先得到用例點數(shù)(UCP-?Use?Case?Points?)，原UCP中用例點數(shù)由角色的用例點數(shù)與用例的用例點數(shù)加和得到。本文介紹方法只計用例的用例點數(shù)。因為角色的用例點數(shù)所占比重很小，一般不超過2%。
用例點數(shù)的計算方法是把用例分成三類，用例分析方法源自于經典用例分析方法[參考文獻2]，給予不同權重。
表1?用例分類權重對應表
| 用例類別 | 說明 | 權重 |
| 簡單（小） | 基本流的步驟不超過3步，備選流或異常不超過3個。 比如簡單用戶界面或一般API | 5 |
| 普通（中） | 基本流的步驟有4~7步，備選流或異常不超過6個。 比如普通界面或復雜API | 10 |
| 復雜（大） | 基本流的步驟?8~?12步，備選流或異常不超過9個。 比如復雜的用戶界面或過程 | 15 |
上述說明中的四個關鍵名詞的解釋如下。
??步驟——步驟定義為單個角色的原子操作。在一個步驟之內，只說明一個角色的連續(xù)動作，角色不發(fā)生轉移；角色變換，是新的步驟。
??基本流——也有稱為主成功場景，達成用例目標的事件流。
??備洗流——也有稱為失敗場景，基本流之外的不能達到用例目標的事件流。
??異常——在基本流中直接說明的異常情況。
用例分類分析的要點有如下。
??不遺漏，要能全面的反映軟件需求，不能有任何遺漏的功能。
??不重復，相同的功能不要反復說明。這會影響數(shù)量的統(tǒng)計。
??考慮所含信息要充分。
??都可以被黑盒測試。
??一般的API用例，即使過程較為復雜，還是簡單用例。
??備選流和異常數(shù)量多時，提升用例的復雜度。
??某一步驟是特別復雜（如一個步驟中角色的連續(xù)動作超過5個），提升用例的復雜度。
??用例基本流步驟超過12步，分拆用例。
根據(jù)以上對應表和規(guī)則，對用例進行識別，然后把計算出各類別的用例數(shù)量，分別乘以權重，取總和就得到用例的用例點數(shù)。公式為：
UCP?=?∑?各類型用例數(shù)量?*?對應的權重
第二步?計算TCF
TCF是指?Technical?Complexity?Factor，技術復雜因數(shù)。原UCP方法設計了13個提問，每個提問都設置了各自的權重，根據(jù)提問，給出從0~5的影響值，然后各權重乘于影響值，再取和得TCF。原TCF考查對象是整個估算范圍。本文給出的方法是對各模板分別考查，因此采用如下簡化取值標準。
表2?項目TCF取值標準
| 權重 | 標準 |
| 0.8 | 代表簡單,?沒有技術難點，30%以上部分有參考對象 |
| 1 | 代表一般 |
| 1.2 | 代表復雜有困難,30%以上部分沒有先例，需要嘗試新技術，比如支持不熟悉的操作系統(tǒng) |
第三步?計算ECF
ECF是指?Environment?Complexity?Factor,?環(huán)境復雜因數(shù)。原UCP方法設計了8個提問，每個提問都設置了各自的權重，根據(jù)提問，給出從0~5的影響值，然后各權重乘于影響值，再取和得ECF。原ECF考查對象是整個估算范圍。本文給出的方法是對各模板分別考查，因此采用如下簡化取值標準。
表3?項目ECF取值標準
| 權重 | 標準 |
| 0.8 | 代表主要開發(fā)人員熟悉類似項目，開發(fā)者必須有2年以上的項目經歷或作為技術負責人（或主要參與人）經歷二個相似項目 |
| 1 | 開發(fā)者必須有1年以上的項目經歷或作為技術負責人（或主要參與人）經歷至少一個相似項目 |
| 1.2 | 開發(fā)者只有不到1年的項目經歷，或沒有項目經歷，并且沒有作為技術負責人經歷相似項目 |
最后一步?計算AUCP
AUCP是指Adjusted?Use?Case?Points。
首先以模塊為單元來進行歸類，識別模塊的TCF和ECF，得到模塊的AUCP，再合計得到總的AUCP。公式為AUCP?=?∑UCP?*?TCF?*?ECF。見下計算表格表4為例。
得到了總的AUCP后，就可以根據(jù)生產率來估算所需的工作量。
表4?UCP計算表格例子
| 模塊 | 用例 | UCP | TCF | ECF | AUCP | ||
| 簡單 | 普通 | 復雜 | |||||
| 錄入 | 6 | 3 | 1 | 75 | 1 | 1.2 | 90 |
| 查詢 | 15 | 10 | 5 | 250 | 0.8 | 1 | 200 |
| 總計 | ? | ? | ? | 325 | ? | 290 | |
???說明：原UCP方法是計算得到UCP總和后再乘以TCF和ECF，TCF和ECF都是考查估算范圍整體情況，分別只有一個值。本文給出的調整UCP方法在實踐中更為簡單，并且分模塊考查，更為細致及準確，得到了實踐者的歡迎。
總結
以上是生活随笔為你收集整理的基于用例点来度量软件规模并管理进度 之一的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 需求用例分析之备选流
- 下一篇： 基于用例点来度量软件规模并管理进度 之二