基於用例點來度量軟體規模並管理進度 之中的一個

來源:互聯網
上載者:User

標籤:style   io   os   ar   使用   for   sp   div   on   

英文名:Based on use case points to measure software size and manage the progress

摘 要 

本文針對軟體項目的規模度量和進度管理,提出了一種新的以用例點的方式來表達和跟蹤的方法。本文具體介紹了經過調整過的用例點度量方法,捨棄了角色相應的用例點數,對用例分類給出了更嚴格的要求,採用了更仔細的步驟定義,並限制了複雜用例的最多步驟。用例的狀態完畢度得到區分,在此基礎上建立了過程中用例的進度跟蹤方法。最後並闡述了在需求可複用情況下的使用方式。

關鍵詞 

用例點 軟體規模 進度 度量


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


引言

軟體規模度量方面,存在了不少難題:

1,開發語言發展快,最新的IDE可以自己主動產生大量代碼

2,維護升級項目的規模難於估算

3,軟體複用後的規模難於估算

4,不同軟體項目的規模相關的比較

傳統軟體規模度量採用源碼行數,但源碼行數有明顯的缺點。因此當前在軟體行業,發展出了多種軟體項目規模的度量方法,較有代表性的例如以下幾種:

Function Points 縮寫FP

Use Case Points 縮寫UCP

User Story Points 

本文依據實踐,參照原UCP方法[參考文獻1],介紹了一種新的以用例點為單位的軟體規模表達方法,並利用這種方法表達軟體開發過程中的進度,對上述的問題進行了處理。


用例點表達規模第一步 計算UCP

首先得到用例點數(UCP- Use Case Points ),原UCP中用例點數由角色的用例點數與用例的用例點數加和得到。本文介紹方法僅僅計用例的用例點數。由於角色的用例點數所佔比重非常小,一般不超過2%。

用例點數的計算方法是把用例分成三類,用例分析方法源自於經典用例分析方法[參考文獻2],給予不同權重。

表1 用例分類權重相應表

用例類別

說明

權重

簡單(小)

基本流的步驟不超過3步,備選流或異常不超過3個。

比方簡單使用者介面或一般API

5

普通(中)

基本流的步驟有4~7步,備選流或異常不超過6個。

比方普通介面或複雜API

10

複雜(大)

基本流的步驟 8~ 12步,備選流或異常不超過9個。

比方複雜的使用者介面或過程

15

上述說明中的四個關鍵名詞的解釋例如以下。

? 步驟——步驟定義為單個角色的原子操作。在一個步驟之內,僅僅說明一個角色的連續動作,角色不發生轉移;角色變換,是新的步驟。

? 基本流——也有稱為主成功情境,達成用例目標的事件流。

? 備洗流——也有稱為失敗情境,基本流之外的不能達到用例目標的事件流。

? 異常——在基本流中直接說明的異常情況。

用例分類分析的要點有例如以下。

? 不遺漏,要能全面的反映軟體需求,不能有不論什麼遺漏的功能。

? 不重複,同樣的功能不要重複說明。這會影響數量的統計。

? 考慮所含資訊要充分。

? 都能夠被黑盒測試。

? 一般的API用例,即使過程較為複雜,還是簡單用例。

? 備選流和異常數量多時,提升用例的複雜度。

? 某一步驟是特別複雜(如一個步驟中角色的連續動作超過5個),提升用例的複雜度。

? 用例基本流步驟超過12步,分拆用例。

依據以上相應表和規則,對用例進行識別,然後把計算出各類別的用例數量,分別乘以權重,取總和就得到用例的用例點數。公式為:

UCP = ∑ 各類型用例數量 * 相應的權重


第二步 計算TCF

TCF是指 Technical Complexity Factor,技術複雜因數。原UCP方法設計了13個提問,每一個提問都設定了各自的權重,依據提問,給出從0~5的影響值,然後各權重乘於影響值,再取和得TCF。原TCF考查對象是整個估算範圍。本文給出的方法是對各模板分別考查,因此採用例如以下簡化取值標準。

表2 項目TCF取值標準

權重

標準

0.8

代表簡單, 沒有技術痛點,30%以上部分有參考對象

1

代表一般

1.2

代表複雜有困難,30%以上部分沒有先例,須要嘗試新技術,比方支援不熟悉的作業系統


第三步 計算ECF

ECF是指 Environment Complexity Factor, 環境複雜因數。原UCP方法設計了8個提問,每一個提問都設定了各自的權重,依據提問,給出從0~5的影響值,然後各權重乘於影響值,再取和得ECF。原ECF考查對象是整個估算範圍。本文給出的方法是對各模板分別考查,因此採用例如以下簡化取值標準。

表3 項目ECF取值標準

權重

標準

0.8

代表主要開發人員熟悉類似項目,開發人員必須有2年以上的項目經曆或作為技術負責人(或主要參與人)經曆二個相似項目

1

開發人員必須有1年以上的項目經曆或作為技術負責人(或主要參與人)經曆至少一個相似項目

1.2

開發人員僅僅有不到1年的項目經曆,或沒有項目經曆,而且沒有作為技術負責人經曆相似項目


最後一步 計算AUCP

AUCP是指Adjusted Use Case Points。

首先以模組為單元來進行歸類,識別模組的TCF和ECF,得到模組的AUCP,再合計得到總的AUCP。公式為AUCP = ∑UCP * TCF * ECF。見下計算表格表4為例。

得到了總的AUCP後,就能夠依據生產率來估算所需的工作量。

表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方法在實踐中更為簡單,而且分模組考查,更為仔細及準確,得到了實踐者的歡迎。








基於用例點來度量軟體規模並管理進度 之中的一個

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.