軟體工程系列文章五

軟體專案的成功率非常低的原因，可能就是專案管理能力太弱。由於軟體本身的特殊性及複雜性，將專案管理思想引入軟體工程領域，就形成了軟體專案管理。

軟體專案管理涉及的範圍

有效的軟體專案管理集中在 4 個 P 上，即人員 (Person)、產品 (Product)、過程 (Procedure) 和專案 (Project)。

軟體專案估算

軟體專案估算涉及人、技術、環境等多種因素，因此，需要一些方法和技術來支持專案的估算，常用的估算方法有下列 3 種：

1. 基於已經完成的類似專案進行估算。
2. 基於分解技術進行估算。
3. 基於經驗估算模型的估算。典型的有 IBM 估算模型、CoCoMo 模型和 Putnam 模型。

上述方法可以組合使用，以提高估算的精度。

COCOMO 估算模型

COCOMO 模型是一種精確的、易於使用的成本估算模型。COCOMO 模型按其詳細程度分為基本 COCOMO 模型、中級 COCOMO 模型和詳細 COCOMO 模型。

基本 COCOMO 模型

基本 COCOMO 模型是一個靜態單變量模型，用於對整個軟體系統進行估算。

其公式如下：

其中，E 表示工作量，單位是人月；D 表示開發時間，單位是月；L 是專案的原始碼行估計值，不包括程式中的註解及文件，其單位是千行程式碼 (KLOC)；a、b、c、d 是常數。

基本 COCOMO 模型可透過估算程式碼行的值 L，然後計算開發工作量和開發時間的估算值。

中級 COCOMO 模型

中間 COCOMO 模型是一個靜態多變量模型，它將軟體系統模型分為系統和部件兩個層次，系統由部件構成，它把軟體開發所需的人力 (成本) 看作是程式大小和一系列「成本驅動屬性」的函數。

中級 COCOMO 模型以基本 COCOMO 模型為基礎，並考慮了 15 種影響軟體工作量的因素，透過工作量調節因子 (EAF) 修正對工作量的估算，從而使估算更合理。

其公式如下：

其中，L 是軟體產品的目標程式碼行數，單位是千行程式碼數；a、b 是常數。

詳細 COCOMO 模型

它將軟體系統模型分為系統、子系統和模組 3 個層次，除包括中級模型所考慮的因素外，還考慮了在需求分析、軟體設計等進一步的成本驅動屬性的影響。

COCOMOII 模型

最初的 COCOMO 模型是得到產業界最廣泛應用和討論的軟體成本估算模型之一，現在它已經演化成更全面的估算模型，稱為 COCOMOII。和其前身一樣，COCOMOII 也是一種階層結構的估算模型，被分為 3 個階段性模型：

1. 應用組裝模型。在軟體工程的前期階段使用，這時使用者介面的原型開發、對軟體和系統互動的考慮、效能的評估以及技術成熟度的評價是最重要的。
2. 早期設計階段模型。在需求已經穩定並且基本的軟體體系結構已經建立時使用。
3. 體系結構階段模型。在軟體的構造過程中使用。

和所有的軟體估算模型一樣，COCOMOII 模型也需要使用規模估算資訊，在模型階層結構中有 3 種不同的規模估算選擇：物件點、功能點和程式碼行。應用組裝模型使用的是物件點；早期設計階段模型使用的是功能點，功能點可以轉換為程式碼行。

進度管理

軟體專案進度管理的目的是確保軟體專案在規定的時間內按期完成。

進度管理的基本原則

1. 劃分
2. 相互依賴性
3. 時間分配
4. 工作量確認
5. 確定責任
6. 明確輸出結果
7. 確定里程碑

進度安排

進度安排的常用圖形描述方法有 Gantt 圖 (甘特圖) 和專案計畫評核術 (Program Evaluation & Review Technique, PERT) 圖。

Gantt 圖

Gantt 圖是一種簡單的水平條形圖，它以行事曆為基準描述專案任務。水平軸表示行事曆時間線 (如時、天、週、月和年等)，每個條形表示一個任務，任務名稱垂直地列在左邊的列中，圖中水平條的起點和終點對應水平軸上的時間，分別表示該任務的開始時間和結束時間，水平條的長度表示完成該任務所持續的時間。當行事曆中同一時段存在多個水平條時，表示任務之間的併發。

Gantt 圖能清晰地描述每個任務從何時開始，到何時結束，任務的進展情況以及各個任務之間的並行性。但是它不能清晰地反映出各任務之間的依賴關係，難以確定整個專案的關鍵所在，也不能反映計畫中有潛力的部分。

PERT 圖

PERT 圖是一個有向圖，圖中的箭頭表示任務，它可以標上完成該任務所需的時間。圖中的節點表示流入節點的任務的結束，並開始流出節點的任務，這裡把節點稱為事件。只有當流入該節點的所有任務都結束時，節點所表示的事件才出現，流出節點的任務才可以開始。事件本身不消耗時間和資源，它僅表示某個時間點。

一個事件有一個事件號和出現該事件的最早時刻和最遲時刻。最早時刻表示在此時刻之前從該事件出發的任務不可能開始；最遲時刻表示從該事件出發的任務必須在此時刻之前開始，否則整個工程就不能如期完成。每個任務還可以有一個寬裕時間 (Slack Time)，表示在不影響整個工期的前提下完成該任務有多少機動餘地。

PERT 圖不僅給出了每個任務的開始時間、結束時間和完成該任務所需的時間，還給出了任務之間的關係，即哪些任務完成後才能開始另外一些任務，以及如期完成整個工程的關鍵路徑。圖中的寬裕時間 (最遲時刻 - 最早時刻) 則反映了完成某些任務時可以推遲其開始時間或延長其所需完成的時間。但是，PERT 圖不能反映任務之間的並行關係。

軟體配置管理

軟體配置管理其主要目標包括：變更識別、變更控制、版本控制、確保變更正確的實現、變更報告。

軟體配置管理其主要內容包括：版本管理、配置支援、變更支援、過程支援、團隊支援、變化報告、稽核支援。

或者：軟體配置識別、變更管理、版本控制、系統建立、配置審核、配置狀態報告。

配置資料庫可以分為以下三類：

1. 開發庫。專供開發人員使用，其中的資訊可能做頻繁修改，對其控制相對寬鬆。
2. 受控庫。在生存期某一階段工作結束時發布的階段產品，這些是與軟體開發工作相關的電腦可讀資訊和人工可讀資訊。軟體配置管理正是對受控庫中的各個軟體項進行管理，受控庫也稱為軟體配置庫。
3. 產品庫。在開發的軟體產品完成系統測試後，作為最終產品存入產品庫，等待交付用戶或現場安裝。

風險管理

一般認為軟體風險包含兩個特性：不確定性和損失。不確定性是指風險可能發生也可能不發生；損失是指如果風險發生，就會產生惡性後果。在進行風險分析時，重要的是量化每個風險的不確定程度和損失程度。為了實現這一點，必須考慮不同類型的風險。

專案風險威脅到專案計畫。也就是說，如果專案風險發生，就有可能拖延專案的進度和增加專案成本。專案風險是指預算、進度、人員 (聘用職員及組織)、資源、利益相關者、需求等方面的潛在問題以及它們對軟體專案的影响。專案複雜度、規模及結構不確定性也屬於專案風險因素。

技術風險威脅到要開發軟體的品質及交付時間。如果技術風險發生，開發工作就可能變得很困難或根本不可能，技術風險是指設計、實現、介面、驗證和維護等方面的潛在問題。此外，規格說明的歧義性、技術的不確定性、技術陳舊以及「前沿」技術也是技術風險因素。技術風險的發生是因為問題比我們所設想的更加難以解決。

商業風險威脅到要開發軟體的生存能力，且常常會危害到專案或產品。5 個主要的商業風險如下：

1. 市場風險。開發了一個沒有人真正需要的優良產品。
2. 策略風險。開發的產品不再符合公司的整體商業策略。
3. 銷售風險。開發了一個銷售部門不知道如何去銷售的產品。
4. 管理風險。由於重點的轉移或人員的變動而失去了高階管理層的支持。
5. 預算風險。沒有得到預算或人員的保證。

(一) 風險識別

風險識別試圖系統化地指出對專案計畫 (估算、進度、資源分配等) 的威脅。識別出已知風險和可預測風險後，專案管理者首先要做的是在可能時迴避這些風險，在必要時控制這些風險。

識別風險的一種方法是建立風險條目檢查表。該檢查表可用於風險識別，並且主要用來識別下列幾種類型中的一些已知風險和可預測風險：

1. 產品規模。與要開發或要修改的軟體的總體規模相關的風險。
2. 商業影響。與管理者或市場所施加的約束相關的風險。
3. 客戶特性。與客戶的素質以及開發者和客戶定期溝通的能力相關的風險。
4. 過程定義。與軟體過程定義的程度以及該過程被開發組織遵守的程度相關的風險。
5. 開發環境。與用來開發產品的工具的可得性及品質相關的風險。
6. 開發技術。與待開發軟體的複雜性及系統所包含技術的「新奇性」相關的風險。
7. 人員才幹及經驗。與軟體工程師的總體技術水平及專案經驗相關的風險。

風險條目檢查表可以採用不同的方式來組織。與上述每個主題相關的問題可以針對每一個軟體專案來回答。根據這些問題的答案，專案管理者就可以估計風險產生的影響。

當然，也可以採用另一種風險條目檢查表格式，即僅僅列出與每一種類型有關的特性，最終給出一組風險因素和驅動因子以及它們發生的機率。風險因素包括效能、成本、支援和進度。風險因素是以如下方式定義的：

1. 效能風險。產品能夠滿足需求且符合其使用目的的不確定程度。
2. 成本風險。能夠維持專案預算的不確定程度。
3. 支援風險。開發出的軟體易於糾錯、修改及升級的不確定程度。
4. 進度風險。能夠維持專案進度且按時交付產品的不確定程度。

(二) 風險預測

風險預測又稱風險估計，它試圖從兩個方面評估一個風險：風險發生的可能性或機率；如果風險發生了所產生的後果。

(1) 風險預測活動

通常，專案計畫人員與管理人員、技術人員一起進行以下 4 步風險預測活動：

1. 建立一個尺度或標準，以反映風險發生的可能性。
2. 描述風險產生的後果。
3. 估算風險對專案和產品的影響。
4. 標注風險預測的整體精確度，以免產生誤解。

一種簡單的風險預測技術是建立風險表。風險表的第 1 列列出所有的風險 (由風險識別活動得到)，第 2-4 列列出每個風險的種類、發生的機率以及所產生的影響。風險所產生的影響可用一個數字來表示：「1」表示災難性的；「2」表示嚴重的；「3」表示輕微的；「4」表示可忽略的。

(2) 評估風險影響

如果風險真的發生，有 3 個因素可能會影響風險所產生的後果，即風險的本質、範圍和時間。風險的本質是指當風險發生時可能會帶來的問題。例如，一個定義很差的與客戶硬體的外部介面 (技術風險) 會妨礙早期的設計和測試，也有可能導致專案後期階段的系統整合問題。風險的範圍包括風險的嚴重性 (即風險有多嚴重) 及風險的整體分布情況 (即專案中有多少部分受到影響或有多少客戶受到損害)。風險的時間是指何時能夠感受到風險的影響及風險的影響會持續多長時間。在大多數情況下，專案管理者希望「壞消息」越早出現越好，但在某些情況下則是越遲越好。

整體的風險顯露度 (Risk Exposure, RE) 可由下面的關係確定：

其中，P 是風險發生的機率，C 是風險發生時帶來的專案成本。

(三) 風險評估

在進行風險評估時，建立了如下形式的三元組：

其中，r_i 表示風險，l_i 表示風險發生的機率，x_i 表示風險產生的影響。

一種對風險評估很有用的技術就是定義風險參考水準。對於大多數軟體專案來說，成本、進度和效能就是 3 種典型的風險參照水準。也就是說，對於成本超支、進度延期、效能降低 (或它們的某種組合)，有一個表明導致專案終止的水準。

在風險評估過程中，需要執行以下 4 個步驟：

1. 定義專案的風險參考水平值。
2. 建立每一組 (R_i, l_i, x_i) 與每一個參考水平值之間的關係。
3. 預測一組臨界點以定義專案終止區域，該區域由一條曲線或不確定區域所界定。
4. 預測什麼樣的風險組合會影響參考水平值。

(四) 風險控制

風險控制的目的是輔助專案組建立處理風險的策略。一個有效的策略必須考慮以下 3 個問題：

(1) 風險避免

應對風險的最好方法是主動地避免風險，即在風險發生前分析引起風險的原因，然後採取措施，以避免風險的發生。

例如專案風險 r_i 表示「頻繁的人員流動」，根據歷史經驗可知，該風險發生的機率 l_i 大約為 70%，該風險產生的影響 x_i 是第 2 級 (嚴重的)。為了避免該風險，可以採取以下策略：

1. 與現有人員一起探討人員流動原因 (如惡劣的工作條件、低報酬、競爭激烈的勞動力市場等)。
2. 在專案開始之前採取行動，設法緩解那些能夠控制的起因。
3. 專案啟動之後，假設會發生人員流動，當有人員離開時，找到能夠保證工作連續性的方法。
4. 組織專案團隊，使得每一個開發活動的資訊都能被廣泛傳播和交流。
5. 制定工作產品標準，並建立相應機制以確保能夠及時建立所有的模型和文件。
6. 同等對待所有工作的評審。
7. 給每一個關鍵的技術人員都指定一個備援人員。

(2) 風險監控

專案管理者應監控某些因素，這些因素可以提供風險是否正在變高或變低的指示。在頻繁的人員流動的例子中，應該監測團隊成員對專案壓力的普遍態度、團隊的凝聚力、團隊成員彼此之間的關係、與報酬和利益相關的潛在問題、在公司內及公司外工作的可能性。

(3) RMMM 計畫

風險管理策略可以包含在軟體專案計畫中，或者風險管理步驟也可以組織成一個獨立的風險緩解、監控和管理計畫 (RMMM 計畫)。RMMM 計畫將所有風險分析工作文件化，並由專案管理者作為整個專案計畫中的一部分來使用。

建立了 RMMM 計畫，而且專案已經啟動之後，風險緩解及檢測步驟也就開始了。風險緩解是一種問題規避活動，而風險檢測是一種專案追蹤活動，這種監測活動有 3 個主要目的：評估所預測的風險是否真的發生了；保證正確地實施了各風險的緩解步驟；收集能夠用於今後風險分析的資訊。在很多情況下，專案中發生的問題可以追溯到不止一個風險，所以風險監測的另一個任務就是試圖找到「起源」(在整個專案中是哪些風險引起了哪些問題)。