-
測量值必須簡單、客觀、易於收集、容易解讀,且不容易誤解。
-
測量值的收集必須自動進行,且不具侵犯性,也就是說,它不能干擾開發人員的活動。
-
測量值必須有助於生命週期早期的品質評量,這時可以有效改進軟體的品質。
-
管理人員和工程人員必須主動運用測量值的絕對值和趨勢,以便用一致的格式來溝通進度和品質。
-
要選取最小測量值集或較大規模的測量值集,取決於專案的特性和環境:如果專案很大,或需要最強的安全或可靠性,且開發和評量小組很懂測量值,收集和分析技術測量值可能會很有幫助。
合約有可能要求收集特定的測量值,組織也可能會嘗試改進它在特定區域的流程技術。 沒有所有情況都一律適用的簡單回答,專案管理人員在產生測量計劃時,必須選取最適合的項目。 不過,第一次引進測量值程式時,在簡單性方面犯錯是合理的。
專案特定方面的測量值,其中包括:
-
大小或複雜度方面的進度。
-
需求或實作、大小或複雜度等之變更率方面的穩定性。
-
變更範圍方面的模組化。
-
錯誤數目和類型方面的品質。
-
錯誤頻率方面的成熟度。
-
專案支出與計劃支出方面的資源
趨勢非常重要,相較於時間中的任何絕對值,更需要監視。
測量值
|
目的
|
樣本測量/視景
|
進度
|
反覆規劃
完成度
|
這些測量也可以依類別和套件來收集
|
穩定性
|
聚合
|
這項測量也可以依反覆和套件來收集
|
適應性
|
聚合
軟體「重做」
|
這項測量也可以依反覆和套件來收集
|
模組化
|
聚合
軟體「報廢」
|
這項測量也可以依反覆來收集
|
品質
|
反覆規劃
重做指標
釋放準則
|
-
錯誤數目
-
問題發現率
-
問題密度
-
繼承深度
-
類別耦合性
-
介面大小(作業數目)
-
置換的方法數目
-
方法大小
這些測量也可以依類別和套件來收集
|
成熟度
|
測試涵蓋面/適當性
使用的強韌度
|
這項測量也可以依反覆和套件來收集
|
支出概況
|
深入瞭解財務
規劃和實際狀況
|
-
人員天數/類別
-
每個月的全職人員
-
花費預算百分比 (%)
|
即使最小的專案都會想追蹤進度來判斷專案是否符合排程和預算,如果不符合,便會想重新預估和判斷需不需要變更範圍。因此,這個最小測量值集會將焦點放在進度測量值上。
-
實現值。這用來重新評估專案其餘部分的排程和預算,以及/或識別變更範圍的需求。
-
問題趨勢。這用來協助專案確定排除問題所需要的工作。
-
測試進度趨勢。這用來判斷實際上完成了多少功能。
以下會詳細說明這些項目。
實現值
最常用來測量進度的方法([PMI96]) 是實現值分析。
測量實現值最簡單的方法是取得所有已完成之作業的原始預估工作總計。您可以將實現值除以專案的原始預估工作總計來算出專案的「完成百分比」。生產力(或效能指數)便是實現值除以完成的作業所花的實際工作。
例如,假設程式碼撰寫工作分成幾項作業,其中許多項現在都已完成。已完成之作業的原始預估是 30 個工作天。專案的總預估工作是 100 天,因此,我們可以預計專案大約完成了 30%。
假設作業已在預算之下完成,且完成只需要 25 天。效能指數便是 30 / 25 = 1.2 或 120%。
我們可以預計專案會以低於預算 20% 完成,並據此縮減我們的預估。
考量
-
效能指數只能用來調整類似作業的預估。及早完成收集需求的作業,並不代表程式碼也會比較快寫完。因此,請只針對類似的作業種類來計算效能指數,只針對類似的作業來調整預估。
-
請考慮其他因素。將來是否由類似的技術人員在類似條件之下執行? 資料是否受到「外物」(嚴重高估或低估的作業)污染? 報告的時間是否一致(例如,即使不支薪,也應該加班)?
-
較新作業的預估是否已列入效能指數中? 若是如此,新作業的預估會比較接近目標,使效能指數更接近 100%。您應該一致地重新預估所有未完成的作業,或採用極端程式設計 (XP) [JEF01] 中的下列作法 -
將原始預估視為一些「點」,透過這些相同的「點」來測量新作業,而不針對實際的效能來進行調整。「點」的好處是可以追蹤效能的增加(或降低)(在 XP 專有名詞中,稱為「專案速率」)。
如果是大型作業(超出 5
天),或有許多已局部完成的作業,您可能會想在您的分析中納入這些因素。請套用一個主觀的「完成百分比」,將它乘以作業的工作預估,並在實現值中併入這一項。指派完成百分比的規則越清晰,結果就越一致。例如,在程式碼通過程式碼檢視之前,程式碼撰寫作業不指派超出
80% 的完成度,便是一項規則。
下面的完整測量值集:專案計劃一節會進一步討論實現值。
問題趨勢
追蹤已開啟和已關閉之問題的趨勢,通常很有幫助。它可以粗略指示問題修正工作是否有重要的待辦事項有待完成,以及逼近它們的速度有多快。
問題趨勢只是 Rational ProjectConsole 所提供的測量值之一。
考量
-
所有變更要求的加權不應該相同,不論它們是影響單行程式碼或造成主要的重新設計,都是如此。您可以利用下列中的某些技術來處理這一點:
-
瞭解外物。需要實質工作的變更要求,便應該如此識別,且應該利用個別作業來追蹤,而不是附隨到一般錯誤修正的儲存區中。如果大量小型修正支配了這個趨勢,請考慮將它們分組,使每個變更要求都代表更一致的工作單元。
-
您可以記錄更多資訊,如主觀的「工作種類」:「小於 1 天」、「1 天」、「小於 5 天」、「大於 5 天」。
-
您可以記錄每項變更要求的預估 SLOC 和實際 SOLC。請參閱下面的小測量值集。
-
欠缺所記錄的問題,可能暗示欠缺測試。請注意檢查問題趨勢時所出現的測試工作層次。
測試進度趨勢
完成度的最終測量是整合了多少功能。
如果您的每項開發作業都代表一組整合功能,實現值趨勢圖便可能足夠。
「測試進度趨勢」是非常簡單的溝通進度的方式。
考量
相對於其他測試案例,有些測試案例可能代表更大的價值或更多的工作。請勿太深入這個圖 - 它只是保證有對於已完成之功能的進度。
對許多專案而言,先前所說明的最小測量值組並不夠。
軟體專案管理是一種統一的架構 [ROY98],它針對所有專案建議了下列測量值組。請注意,這些測量值需要每項變更要求的來源程式碼行 (SLOC) 預估值和實際值,這又需要花額外工夫來收集。
測量值和初始測量值
SLOC 總計
|
SLOCt = 估計的程式碼總大小。在更深入瞭解需求、解決方案更成熟之後,可能會有大幅改變。請併入小組可能會改變的重複使用的軟體。
|
配置控制下的 SLOC
|
SLOCc = 現行基準線
|
關鍵問題
|
SCO0 = 類型 0 SCO 的數目(其中 SCO 是軟體變更順序 - 變更要求的另一個詞彙)
|
一般問題
|
SCO1 = 類型 1 SCO 的數目
|
改進要求
|
SCO2 = 類型 2 SCO 的數目
|
新特性
|
SCO3 = 類型 3 SCO 的數目
|
SCO 的數目
|
N = SCO0 + SCO1 + SCO2
|
開啟重做(毀損)
|
B = 因 SCO1 和 SCO2 而累加的毀損 SLOC
|
已關閉重做(修正)
|
F = 累加的修正 SLOC
|
重做工作
|
E = 為了修正類型 0/1/2 SCO 而花費的累加工作
|
使用時間
|
UT = 給定基準線在實際使用情境之下操作的時數
|
終端產品品質測量值
從這一小組測量值中,可以衍生出一些有趣的測量值:
報廢比例
|
B/SLOCt,報廢產品的百分比
|
重做比例
|
E/工作總計,重做工作的百分比
|
模組化
|
B/N,每一 SCO 的平均毀損
|
適應性
|
E/N,每一 SCO 的平均工作
|
成熟度
|
UT/(SCO0 + SCO1),問題之間的平均時間
|
可維護性
|
(報廢比例)/(重做比例),維護生產力
|
進度指標
重做穩定性
|
B - F,一段時間內的毀損和修正
|
重做待辦事項
|
(B-F)/SLOC,目前開啟的重做
|
模組化趨勢
|
模組化,一段時間內
|
適應性趨勢
|
適應性,一段時間內
|
成熟度趨勢
|
成熟度,一段時間內
|
以下是要測量的項目:
-
流程 - 為了產生軟體產品(及其他工作成果)而呼叫的作業序列;
-
產品 - 流程的工作成果,其中包括軟體、文件和模型;
-
專案 - 專案資源、作業和工作成果的全部;
-
資源 - 專案所能使用的人員、方法和工具、時間、工作和預算
如果要完整描述流程特性,應該在正式規劃作業的最低層次上進行測量。作業由專案管理人員利用一組最初的預估來規劃。之後,應該保留一段時間內實際值及任何更新預估的記錄。
測量值
|
備註
|
持續時間
|
作業的經歷時間
|
工作
|
人員工作單位(人員小時、人員天數、...)
|
輸出
|
工作成果及其大小和品質(請注意,這會將問題併入測試活動輸出之中)
|
軟體開發環境用法
|
CPU、儲存體、請注意,軟體工具、設備(工作站、PC)、可移除項目。軟體工程環境中心 (SEEA) 可收集專案的這些項目。
|
問題、發現率、更正率。
|
也必須收集總修復時間/工作和總報廢/重做情況(在可測量的情況下);大體上是取自針對問題(視為工作成果)而收集的資訊。
|
變更要求、施行率、除去率。
|
備註如同上面的時間/工作。
|
可能會影響這些測量值的其他發生事件(不拘文字形式)
|
這是一項測量值,因為它是影響流程的事件記錄。
|
成員、設定檔(一段時間內)和特性
|
|
人員接替
|
這是一項很有用的測量值,在後置審查的檢視中,它可能會說明某個流程的運行特別好或不好的原因。
|
工作應用
|
在執行規劃活動期間的工作方式(針對工作來正式記錄時間,以進行成本帳目管理),有助於說明生產力的各種變化:以下是某些工作應用子類別的範例:
-
訓練
-
熟悉
-
管理(如由小組負責人來管理)
-
管理
-
研究
-
工作程序 - 依工作成果來建立這方面的記錄會很有用,請嘗試將「思考」時間和擷取時間分開,文件尤其如此。專案管理人員會因而知道工程師花多少時間來處理文件。
-
時間損失
-
會議
-
檢驗、輕鬆演練、檢視 - 準備和會議工作(其中有一部分是個別活動,將針對特定檢視作業來記錄它們的時間和工作)
|
檢驗、輕鬆演練、檢視(在作業期間 - 不是個別排程的檢視)
|
記錄這些項目的數目及其持續時間,以及產生的問題數目。
|
流程偏差(產生為不符合標準,需要專案變更)
|
記錄這些項目的數目及其嚴重性。這是一個指標,表示可能需要更多教育、流程可能誤用,或流程的配置方式不正確
|
流程問題(產生為流程問題,需要流程變更)
|
記錄這些項目的數目及其嚴重性。在後置審查的檢視中,這是很有用的資訊,也是對於軟體工程流程中心 (SEPA) 的重要回饋。
|
Rational Unified Process (RUP) 中的成果稱為工作成果,包括文件、模型或模型元素。模型是類似事物(模型元素)的集合,因此這裡列出建議的測量值及它們適用的模型:測量值是作為整體或作為單一元素而套用到模型上,通常都很明顯。當不清楚時,便提供說明文字。
工作成果特性
以下是我們通常會感興趣的測量特性:
-
大小 - 模型中事物數目的測量、某事物的長度、某事物的範圍或群集
-
品質
-
問題 - 指出工作成果無法依照指示來執行,或不符合規格,或有其他不恰當的特性
-
複雜度 - 測量結構或演算法的複雜程度:結構越複雜,也越難理解和修改,複雜結構已證明為比較容易失敗
-
耦合性 - 測量系統元素交互連接的廣泛程度
-
內聚力 - 測量元素或元件符合已定義好單一目的這項需求的程度
-
初始度 - 類別的作業或方法可以從類別所提供的其他作業或方法組成的程度
-
完成度 - 測量工作成果符合所有需求的程度(明示和隱含 -
專案管理人員應該儘可能使它明確,以限制預期未獲實現的風險)。在這裡,我們尚未選擇區分充足和完成。
-
可追蹤性 - 指出低層次的工作成果滿足了高層次的需求,從另一方面來看,是指任何層次的工作成果都有存在的理由
-
變化性 - 工作成果為了問題或需求變更而變更或不確定的程度
-
工作 - 產生工作成果所需要的工作測量(人員時間單位)
並非所有這些特性都適用於所有工作成果:下表會隨同特定工作成果來詳述相關的特性。許多測量值都是針對一項特性來列出,全部都可能相關,因為它們從多種角度提供了特性的完整說明。例如,當考慮使用案例的可追蹤性時,最後全都必須可追蹤到(測試的)實作模型:在過渡期間,專案管理人員仍會想知道有多少使用案例可追蹤到分析模型,以便測量進度。
文件
建議的測量值適用於所有 RUP 文件。
特性
|
測量值
|
大小
|
頁面計數
|
工作
|
正式作業、變更和修復的人員時間單位
|
變化性
|
變更和問題(已開啟、已關閉)的數目;變更頁數
|
品質
|
直接利用問題計數來測量
|
完成度
|
不直接測量:透過檢視來判斷
|
可追蹤性
|
不直接測量:透過檢視來判斷
|
模型
需求
需求屬性
這實際上是一個模型元素。
特性
|
測量值
|
大小
|
-
需求總數 (= Nu+Nd+Ni+Nt)
-
要追蹤到使用案例的數目 ( = Nu)
-
只要追蹤到設計、實作、測試的數目 ( = Nd)
-
只要追蹤到實作、測試的數目 ( = Ni)
-
只要追蹤到測試的數目 ( = Nt)
請注意,這會將需求分割成以使用案例來建模和不以使用案例來建模兩種。預期的情況是,將利用使用案例的可追蹤性來說明指派給使用案例的需求,以便追蹤設計、實作和測試。
|
工作
|
|
變化性
|
|
品質
|
|
可追蹤性
|
|
使用案例模型
特性
|
測量值
|
大小
|
-
使用案例數目
-
使用案例套件數目
-
報告的使用案例層次(請參閱 IBM 網站所提供的白皮書,"The Estimation of Effort and Size based on Use
Cases")
-
情境數目,總計和個別使用案例
-
參與者數目
-
使用案例長度(如事件流程頁數)
|
工作
|
|
變化性
|
|
品質
|
-
報告的複雜性(在類別層次上 0-5,從 COCOMO 類推 [BOE81];複雜性範圍在愈高的抽象層次上愈窄 - 請參閱 IBM 網站上的 "The Estimation of Effort and Size based on Use Cases" 白皮書)
-
問題 - 問題數目,依嚴重性(已開啟、已關閉)
|
完成度
|
-
已完成的使用案例(已檢視且在配置管理之下,沒有未完成處理的問題)/已識別的使用案例(或預估的使用案例數目)
-
需求至 UC 可追蹤性(從需求屬性開始)
|
可追蹤性
|
|
設計
分析模型
特性
|
測量值
|
大小
|
-
類別數目
-
子系統數目
-
子系統之子系統的數目...
-
套件數目
-
每個類別(內部、外部)的方法數目
-
每個類別(內部、外部)的屬性數目
-
繼承樹的深度
-
子項數目
|
工作
|
|
變化性
|
|
品質
|
複雜度
|
-
類別回應 (RFC):這可能比較不容易計算,因為它需要一組完整的互動圖。
|
耦合性
|
|
內聚力
|
|
問題
|
|
完成度
|
-
完成的類別數目/預估的類別數目(已識別)
-
分析可追蹤性(使用案例模型)
|
可追蹤性
|
不適用 - 分析模型變成設計模型。
|
這裡出現一些可能不熟悉的 OO 專用技術測量值 - 繼承樹深度、子項數目、類別回應、物件之間的耦合性等等。請參閱 [HEND96]
,以取得這些測量值之意義和歷程的詳細資料。這些測量值許多最初是由 Chidamber 和 Kemerer 提出(請參閱 "A metrics suite for object oriented design", IEEE
Transactions on Software Engineering, 20(6), 1994),但我們是依照 [HEND96]
的建議而在這裡套用它們,我們偏好該項工作所提出的 LCOM 定義(欠缺方法內聚力)。
設計模型
特性
|
測量值
|
大小
|
-
類別數目
-
設計子系統的數目
-
子系統之子系統的數目...
-
套件數目
-
每個類別(內部、外部)的方法數目
-
每個類別(內部、外部)的屬性數目
-
繼承樹的深度
-
子項數目
|
工作
|
|
變化性
|
|
品質
|
複雜度
|
-
類別回應 (RFC):這可能比較不容易計算,因為它需要一組完整的互動圖。
|
耦合性
|
|
內聚力
|
|
問題
|
|
完成度
|
|
可追蹤性
|
實作模型中的類別數目/類別數目
|
實作
實作模型
特性
|
測量值
|
大小
|
-
類別數目
-
檔案數目
-
實作子系統數目
-
子系統之子系統的數目...
-
套件數目
-
每個類別(內部、外部)的方法數目
-
每個類別(內部、外部)的屬性數目
-
方法大小*
-
屬性大小*
-
繼承樹的深度
-
子項數目
-
完成時的估計大小*
|
工作
|
|
變化性
|
-
問題和變更要求的數目
-
每項更正性或完成性變更的毀損 *,包括預估(修正之前)和實際(結束之時)
|
品質
|
複雜度
|
|
耦合性
|
-
子項數目
-
物件之間的耦合性(類別展開)
-
訊息傳遞耦合性 (MPC)***
|
內聚力
|
|
問題
|
|
完成度
|
-
測試的類別單元數目/設計模型中的類別數目
-
整合的類別數目/設計模型中的類別數目
-
實作可追蹤性(使用案例模型)
-
實作可追蹤性(需求屬性)
-
測試模型可追蹤性乘以測試完成度
-
主動式的整合和系統測試時間(從測試流程中累計),也就是說,含系統作業的時間(用來計算成熟度)
|
* 應該先選擇某個測量程式碼大小的方法,再一致地套用,例如無備註、無空白。請參閱 [ROY98]
,取得關於「程式碼行」作為一項測量值的價值和應用的討論。另外,也請參閱相同的參考資料 以取得「毀損」的定義。
** 迴圈複雜度並未被普遍接受 - 當套用於類別方法之時,尤其如此。請參閱 [HEND96],以取得這個測量值的討論。
*** 最早是來自 Li 和 Henry 的 "Object-oriented metrics that predict maintainability", J. Systems and Software, 23(2), 1993,[HEND96]中也有相關說明。
測試
測試模型
特性
|
測量值
|
大小
|
|
工作
|
-
案例正式作業等的人員時間單位(正式作業、變更和修復分開)
|
變化性
|
|
品質
|
-
問題 - 問題數目,依嚴重性(已開啟、已關閉)(這些都是針對測試模型本身而產生的問題,而不是測試小組針對其他軟體而產生的問題)
|
完成度
|
|
可追蹤性
|
-
在測試評估摘要中,報告為順利完成的測試案例數目/測試案例數目
|
管理
變更模型 - 這是關於一致地呈現的觀念模型 - 將從所用的任何系統收集測量值來管理變更要求。
特性
|
測量值
|
大小
|
-
問題和變更要求的數目(依嚴重性和狀態),也分類成完成性變更的數目、調適性變更的數目及更正性變更的數目。
|
工作
|
|
變化性
|
|
完成度
|
-
發現的問題數目/預期的問題數目(如果使用可靠性模型的話)
|
專案計劃(「軟體開發計劃」的第 4.2 節)
這些都是運用實現值技術來管理專案所得出的測量;它們稱為「成本/排程控制系統準則 (C/SCSC)」。上述最小測量值集的一部分說明了簡單的實現值技術。您可以利用相關的測量值來執行更詳細的分析,其中包括:
-
BCWS,排程工作的預算成本 (Budgeted Cost for Work Scheduled)
-
BCWP,執行工作的預算成本 (Budgeted Cost for Work Performed)
-
ACWP,執行工作的實際成本 (Actual Cost of Work Performed)
-
BAC,完工預算 (Budget at Completion)
-
EAC,預計完工成本 (Estimate at Completion)
-
CBB,合約預算基礎 (Contract Budget Base)
-
LRE,最新修訂預估 (Latest Revised Estimate (EAC))
成本和排程變異的衍生因素。關於在軟體專案管理上運用實現值方法的討論,請參閱 [ROY98]。
專案必須用類型、大小、複雜度和形式(不過,類型、大小和複雜度通常便決定了形式)來描述特性,因為這些方面決定了關於較低階測量各種臨界值的預期。其他各項限制應該放在合約(或規格)中。測量值從流程衍生而來,產品和資源會擷取所有其他專案層次的測量值。專案類型和領域可以利用文字說明來記錄,以確定有足夠的細節可供精確描述專案的特性。請依照成本、工作、持續時間、將開發的程式碼大小、要交付的功能點等來記錄專案大小。專案的複雜度也可以說明,但這有點主觀
- 方式是將專案放在一個圖表中,圖表顯示它相對於其他已完成之專案的技術和管理複雜度。[ROY98], 圖 14-1
顯示這種圖解。
[ROY98] 中描述的衍生測量值(「專案管理人員」的主要指標)可以從在產品和流程上收集的測量值取得。 它們是:
-
模組化 = 實作模型每項完成性或更正性變更的平均毀損 (NCNB*)
-
適應性 = 實作模型每項完成性或更正性變更的平均工作
-
成熟度 = 主動式測試時間/更正性變更的數目
-
可維護性 = 維護生產力/開發生產力 = [實際累加修正/完成性或更正性變更的累加工作]/[完成時的預估 NCNB 數目/完成時的預估正式作業工作]
-
重做穩定性 = 累加毀損-累加修正
-
重做待辦事項 = [累加毀損-累加修正]/測試的 NCNB 單元
* NCNB 是無備註、無空白程式碼大小。
進度應該以工作成果達成率測量值並對照專案計劃來報告 - 對於運作軟體的製作設定特定的權值(從實現值的觀點)。
如果採用 COCOMO 之類的預估模型(請參閱 [BOE81]),
則應該記錄各種比例係數和成本動因。這些實際上便形成了非常詳細的專案特性。
將測量的項目包括人(經驗、技術、成本、效能)、方法和工具(生產力和品質的效果、成本)、時間、工作、預算(消耗的資源、剩餘的資源)。
人員配置設定檔的記錄應該跨越一個時段,顯示類型(分析師、設計者等)、等級(暗示成本),以及配置的小組。實際和計劃都應該記錄。
再說明一次,COCOMO 模型需要描述人員經驗和能力及軟體開發環境的特性,它是保留這些測量值的好架構。
支出、預算和排程資訊都將來自專案計劃。
|