測量主要是為了控制專案,進而管理專案。透過測量,我們可以根據完成率、品質、需求達成率等,評估我們目前距離預定的目標有多遠。
我們也可以根據過去的經驗來測量,更準確預估新專案的工作量、成本及品質。最後,透過測量可以評估流程效能的一些重要層面在一段期間內改善的情形,看出改革的成效。
測量專案的一些重要層面無可避免地會增加成本。所以,我們不會測量全部的東西。我們必須為這項工作訂定非常準確的目標,且只收集供我們滿足這些目標的測量值即可。
有兩種目標:
-
知識目標:以評估、預期、監視等動詞來表達。您一定想要充分瞭解整個開發流程。例如,您可能想要評估產品的品質、取得資料來預估測試工作量、監視測試涵蓋率,或追蹤需求變更。
-
變動或達成目標:這些以增加、減少、改進或達成等動詞來表達。您通常比較關心事物在不同的反覆或專案之間如何改變或改進。
範例:
-
對照計劃來監督進度
-
提昇客戶滿意度
-
提昇生產力
-
提昇預測能力
-
提高重複使用性
這些一般性管理目標尚無法直接轉換成測量值。必須先轉換成一些更小的子目標(或動作目標),這些子目標代表專案成員達成目標所必須採取的動作。我們還必須確定相關人員已瞭解其優點。
範例
提昇客戶滿意度的目標可以拆解為:
-
定義客戶滿意度
-
測量客戶對多個版本的整體滿意度
-
確認滿意度已改善
提昇生產力的目標可以拆解為:
-
測量投入成本
-
測量進度
-
計算在多次反覆或多個專案上的生產力。
-
比較結果
然後,部份子目標(不是全部)需要收集一些測量值。
範例
測量客戶滿意度可以從下列來源導出
-
客戶調查(客戶在各不同層面上打分數)
-
撥打客戶支援中心的電話數量和密集程度。
如果需要詳細資訊,請參閱 [AMI95]。
將這些目標分類的一種有效方法是依組織、專案及技術需求來分類。這樣可讓以上討論的推敲工作形成一個架構。
組織必須瞭解(或改進)每一個「項目」的成本、縮短建置時間(上市時間),在交付已知品質的產品時(客觀和主觀),也必須瞭解適當的維護需求。組織可能時常(或持續)需要改善效能來維持競爭力。為了降低風險,組織必須瞭解員工的技術水準和情境經驗,並確定有其他資源和能力可做為在特定專業領域中競爭的後盾。組織必須有能力引進新的技術並決定該技術的成本效益。下表列出軟體開發組織在這些需求上有關的幾種測量值的範例。
關切重點
|
測量值
|
項目成本
|
每一行程式碼的成本、每一個功能點的成本、每一個使用案例的成本。每一行程式碼、功能點或使用案例的正常投入成本 (遍及指定的生命週期部份、程式語言、職務等級等)。請注意,這些測量值通常不是單純的數字 -
取決於交付的系統大小及排程是否縮短。
|
建構時間
|
每一行程式碼或每一個功能點的經歷時間。請注意,這一樣也取決於系統大小。增加人員也可以縮短排程,但有一定的限度。確切的限制視組織的管理能力而定。
|
交付產品的問題密度
|
每一行程式碼或每一個功能點的問題數(交付之後才發現)。
|
主體品質
|
易用性、操作性、客戶接受度。雖然很模糊,但已有辦法量化。
|
維護性
|
每年的每一行程式碼或功能點的成本。
|
技能、經驗背景
|
「人力資源」小組可能保存某種技能與經驗資料庫。
|
技術能力
|
-
工具 - 組織應該瞭解哪些是一般用途,以及不常使用的工具所需具備的專業能力。
-
流程的成熟度 - 例如,組織在 SEI CMM 評比上的等級。
-
專業能力 - 組織有能力從事什麼應用程式領域?
|
流程改善的測量基準值
|
-
流程執行時間和投入成本。
-
問題率、因果分析統計值、修正率、報廢重做比例。
|
專案必須符合下列準則才能交付:
-
功能面和非功能面的必備性能
-
各項技術限制
-
預算和排程限制
-
特定的轉換、操作及維護特性
專案管理人員必須瞭解目前是否朝向這些目標邁進,下表進一步指出一些關於專案測量的概念:
關切重點
|
專案投入成本和預算
|
專案排程
|
轉換/安裝
|
操作
|
維護性/支援能力
|
功能面需求
-
需求有效、完整嗎?
-
需求重複出現嗎?
-
需求按照計劃實現嗎?
|
非功能面需求
-
效能
-
容量
-
系統有能力在同一時間應付所要求的使用者數量嗎?網站有能力處理所要求的每秒點閱次數嗎? 有足夠的儲存體可保存所要求的客戶記錄筆數嗎?
-
品質因素
-
可靠性:系統失效可接受的頻率、導致系統失效的原因?
-
使用性:系統使用起來簡單又方便嗎?需要多久才能上手及需要什麼技術?
-
容錯性/健全性/恢復性/存活性:系統在出現問題時可以繼續運作嗎?系統有辦法處理輸入錯誤的情形嗎?系統有能力在失效之後自動回復嗎?
-
專業工程需求
-
安全性:系統運作對生命或財產(有形和無形)不會造成危險嗎?
-
保密性/穩私性:系統可防止未獲授權存取機密資料嗎?系統可防止惡意入侵嗎?
-
環境影響:系統符合環境需求嗎?
-
其他法規或法律要求
-
限制式
-
外部環境:系統有能力在規定的環境中運作嗎?
-
資源、主機、目標:系統符合 CPU、記憶體、語言、軟硬體環境、限制嗎?
-
使用現成商用產品 (COTS) 或其他現有的軟體:系統符合重複使用性限制嗎?
-
人員可用性和技能:人員可用數量和類型足夠建置系統嗎?
-
介面支援/相容性:系統可支援與其他系統之間的存取嗎?
-
重複使用性:為了可重複使用系統,該採取什麼措施?
-
強制標準:系統和開發方法相符嗎?
-
其他設計限制(例如架構、演算):系統採用必要的架構樣式嗎?使用規定的演算法嗎?
|
這份清單包含專案管理人員關切的許多重點(但不是全部)。其中很多需要收集和分析測量值,有些也需要進行特定的測試(取得測量結果)以回答提出的問題。
許多專案需求沒有直接的測量基準值,即使有標準,也可能不確定該做什麼或應該如何改善。低品質的屬性可以組合構成各種高品質屬性的品質,例如 ISO 標準
9126(軟體品質特性和測量值)規定的屬性及以上在「專案需求」中提及的屬性。這些技術測量基準值屬於工程(結構和行為特特性和效果(涵蓋流程與產品),構成專案層次測量值需求。下表的屬性已用來導出 Rational Unified
Process 工作成果與流程的一組測量值樣本。請參閱 工作成果準則:測量值。
品質
|
屬性
|
需求的妥善性
|
-
變化性:變動頻率、引進新需求的速度
-
有效性:這些是正確的需求嗎?
-
完整性:遺漏任何需求嗎?
-
表達正確性:需求描述適當嗎?
-
明確性:說明一目瞭然嗎?
|
設計的妥善性
|
-
耦合性:系統元素之間連線的密集度?
-
凝聚性:每一個元件只有單一明確的用途嗎?
-
原始性:類別的方法或操作可以從該類別的其他方法或操作來建構嗎?如果可以,則類別不是原始的(理想的特性)。
-
完整性:設計完整地實現需求嗎?
-
變化性:架構變更的頻率。
|
實作的妥善性
|
-
大小:實作距離最小規模(解決問題)的成效如何?實作將會符合限制嗎?
-
複雜性:程式碼的演算法很困難或錯綜複雜嗎?很難理解和修改嗎?
-
完整性:實作準確地實現所有設計嗎?
|
測試的妥善性
|
-
涵蓋率:在軟體上測試推演的成果如何?全部的指令都經過一組測試執行了嗎?測試在程式碼中循著許多路徑推演嗎?
-
有效性:測試本身正確地反映需求嗎?
|
流程的妥善性(最低層次)
|
-
問題率、問題原因:一項作業的問題發生率有多高及原因是什麼?
-
投入成本和持續時間:一項活動需要的多久時間完成和投入多少人力?
-
生產力:一項活動的每單位人力有多少產出?
-
工作成果的妥善性:一項作業的輸出有多高的問題率?
|
流程/工具變動的效益
|
(同於流程的妥善性,但僅百分比變動,而非全部的值):
-
問題率、問題原因
-
投入成本和持續時間
-
生產力
-
工作成果的妥善性
|
關於測量值概念的深入探討,請參閱 [WHIT97]。
我們區分為兩種測量值:
-
測量值是一個實體的可測量屬性。例如,專案投入成本是專案規模的一項測量基準值(亦即測量值)。您必須加總專案的所有時程表預訂數據,才能計算這個測量值。
-
初始測量值是一個用來計算測量值的原始資料項目。在上述範例中,時程表預訂數據就是初始測量值。初始測量值通常是存在資料庫中的測量值,不適合獨立解釋。
每一個測量值由一或多個收集到的測量值構成。因此,必須明確定義每一個初始測量值及其收集流程。
支援「變動」或「達成」目標的測量值,通常是時間(或反覆、專案)的「一階導數」。在此強調的是趨勢,不是絕對值。為了「改善品質」,我們必須檢查已知問題的數量是否隨著時間而遞減。
測量值的範本
名稱
|
測量值的名稱及任何已知的同義字。
|
定義
|
使用此測量值來測量的實體屬性、如何計算測量值,以及計算的來源初始測量值。
|
目標
|
列出此測量值相關的目標和問題。也提出一些說明,解釋為何收集測量值。
|
分析流程
|
測量值的用途。測量值解譯的前置條件(例如,其他測量值的有效範圍)。目標值或趨勢。採用的分析技術模型和工具。隱含的假設(例如,環境或模型)。校正流程。儲存體。
|
責任
|
由誰負責收集和彙總測量資料、準備報告及分析資料。
|
初始測量值的範本
名稱
|
初始測量值的名稱
|
定義
|
以專案的環境來明確說明測量值
|
收集程序
|
收集流程的說明。採用的資料收集工具及表單。在生命週期內收集資料的時間點。採用的驗證流程。資料的儲存位置、格式、精準度。
|
責任
|
誰負責收集資料。誰負責驗證資料。
|
有兩項作業:
每一個開發週期定義一次測量計劃 - 在初始階段、在一般規劃活動,有時是在開發案例的流程配置中。在專案期間,就像軟體開發計劃的任何部份一樣,可能隨時需要檢討測量計劃。
收集測量基準值會不斷重複進行,至少每一次反覆時收集一次,有時更頻繁;例如,在長達數個月的一個反覆期間,每週收集一次。
收集到的測量值會成為「狀態評估」文件的一部份,可用來評估專案的進度和健全性。也可能累積起來,供整個組織以後用於專案估算和預測趨勢。
估算
專案管理人員的主要工作就是規劃 - 根據預算和排程來分配各項作業的資源。從判斷可能的成果來估算投入成本與排程,或反過來估算 - 資源和排程有限,必須估算可能的成果。基於規劃的目的,估算通常必須根據其他因素來計算資源需求 -
通常是規模和生產力。
預測
預測很像估算,通常是關於計算一些因素的未來值,而且是根據該因素及其他影響因素的現值來計算。例如,假設有一份效能資料的樣本,則可從中瞭解(預測)系統在負荷滿載的情況下、或資源有限或退化的配置中如何運作。可靠性預測模型中利用問題率資料,預測系統何時可達到一定的可靠性水準。規劃一項活動之後,專案管理人員需要資料來預測完成日期和完工投入成本。
評估
評估用來建立現況與臨界值的比較,譬如說,可以掌握趨勢、比較替代方案,或做為估算或預測的基礎。
如需詳細瞭解專案管理的測量值,請參閱 [ROY98]。
|