《軟件工程基礎》第13章 軟件項目管理

1、13.1 軟件項目管理概述軟件項目管理的目標 組織實施軟件工程項目，采用了許多技術手段和管理措施，最終希望項目取得成功。通常認為，項目成功的標志，也是項目管理人員爭取的目標，應該包括以下幾個方面。（1）達到項目預期的軟件產品功能和性能要求。一般而言，就是軟件產品達到了用戶已認可的需求規(guī)格說明的要求。（2）時限要求。項目應在合同規(guī)定的期限內完成。 （3）項目開銷限制在預算之內。 按RSPressman的觀點，軟件項目管理涉及的幾個主要方面是人員、產品、過程和項目，即所謂4P（People、Product、Process、Project）。 （1）人員管理 美國卡內基梅隆大學軟件工程研究所的Bil

2、l Curtis在1994年發(fā)表了“人員管理能力成熟度模型”（people capability maturity model，P-CMM）。該模型力圖通過吸引、培養(yǎng)、激勵、部署和騁用高水平的人才來提升軟件組織的軟件開發(fā)能力。人員管理涉及：13.1 軟件項目管理概述軟件項目管理涉及的幾個方面 共利益者。 包括： 項目的高級管理者負責項目商務問題的決策； 項目經理負責項目的計劃與實施以及開發(fā)人員的組織與管理； 開發(fā)人員項目開發(fā)的實施者； 客戶提出需求并代表用戶與開發(fā)人員交往的人員； 最終用戶直接使用項目成果（產品）的人員。 團隊負責人。在小項目的情況下，項目經理就是團隊負責人。而大型項目也許會有

3、若干個設計、編程團隊或是若干個測試團隊。團隊負責人除去負有團隊日常工作的安排、組織和管理之外，還應特別注意發(fā)揮團隊成員的潛能。13.1 軟件項目管理概述 團隊集體。團隊內部有分工是必要的，但必須很好地配合，做到步調一致，為此必須強調以下3點。 個人的責任心，這是團隊完成工作的基本條件。 互相信任、尊重以及互相支持。 充分的交流與溝通。（2）產品管理 軟件產品是軟件項目的成果和預期的目標，這種無形的產品在開發(fā)出以前，對其進行管理有一定的困難。然而，項目經理必須在項目開始時就明確項目的以下三個目標： 產品的工作環(huán)境。13.1 軟件項目管理概述 產品的功能和性能。 產品工作處理的是什么數據，經它處理

4、后得到什么數據。 顯然，只有明確了項目的這些基本要求才能著手項目管理的各項工作，如項目估算、風險分析、項目計劃的制定等。 （3）過程管理 過程在軟件工程項目中是重要的因素，它決定著項目中開展哪些活動以及對活動的要求和開展活動的順序。（4）項目管理 項目管理的任務是如何利用已有的資源，組織實施既定13.1 軟件項目管理概述的項目，提交給用戶適用的產品。項目管理要開展的主要工作可分為3類。 計劃及計劃管理。包括項目策劃及計劃制定、項目估算、風險分析及風險管理、進度管理、計劃跟蹤與監(jiān)督。 資源管理。包括人員管理（人員安排、使用）、成本管理、信息管理。 成果要求管理。包括需求管理、配置管理、質量管理。

5、 13.1 軟件項目管理概述 軟件工程項目的計劃是指導項目開展的綱領性文件，必須認真對待，通常在項目的目標確定和被開發(fā)的軟件基本功能確定之后，就應該著手項目計劃的制定工作。而項目估算是制訂計劃的基礎和依據。項目策劃與項目估算13.2 項目估算 項目策劃是在項目開展初期階段的重要工作，其主要目標是得到項目計劃，或者說計劃（plan）是策劃（planning）的結果。項目策劃中需要開展的活動有如下幾項：（1）確認并分析項目的特征。（2）選擇項目將遵循的生存期模型，確定各階段的任務。（3）確定應得到的階段性工作產品以及最終的產品。（4）開展項目估算，包括估算產品規(guī)模、工作量、成本以及所需的關鍵計算機

6、資源。（5）制訂項目進度計劃。（6）對項目風險進行分析。（7）制訂項目計劃。 在項目估算中，要解決的問題是項目實施的幾個主要屬性，即將要開發(fā)產品的規(guī)模（size）、項目所需的工作量（effort）以及項目的成本（cost）。 13.2 項目估算（1）規(guī)模。項目的規(guī)模指的是得到最終軟件產品的大小。一般以編程階段完成以后得到程序的代碼行表示，如以1千代碼行為單位，記為KLOC。當然，在項目的開始只是對代碼行的估計值。另一表示方法是功能點，記為FP，它是根據軟件需求中的功能估算的。（2）工作量。項目的工作量按項目將要投入的人工來考慮，以一個人工作一個月為單位，記為“人月”。（3）成本。軟件項目的成本

7、通常只考慮投入的人工成本，如某項目投入的總人工費用為12萬元。13.2 項目估算 一個軟件組織在完成多個項目以后積累了一些數據，進行成本分析后便可得到自己的生產率數值和人工價格。 生產率是平均每個人月完成的源程序行數，可記為KLOC/人月或FP/人月。 人工價則為每人月的價值。 有了這兩個數值，如果在估出項目規(guī)模以后就可以很容易得到項目的工作量和成本，即工作量=規(guī)模/生產率成本=工作量人工價13.2 項目估算 功能點方法（function point）簡稱FP方法，該方法克服了項目開始時無法得知源程序行數的實際困難，從軟件產品的功能度（functionality）出發(fā)估算出軟件產品的規(guī)模。 1

8、功能度 功能點方法是以項目的需求規(guī)格說明中已經得到確認的軟件功能為依據，著重分析要開發(fā)系統的功能度，并且認為，軟件的大小與軟件的功能度相關，而與軟件功能如何描述無關，也與功能需求如何設計和實現無關。 為具體說明功能點方法，區(qū)分各種不同的功能，需要建立應用系統邊界的概念。應用系統邊界把我們正在開發(fā)的應用13.2 項目估算項目估算的功能點方法系統與用戶和與其相關的應用系統分割開來。內部功能僅限于應用系統的邊界之內，而外部功能則是跨邊界的。 右圖給出了待開發(fā)的應用系統A及其邊界。該系統有它的用戶和與其相關的應用系統B。圖中系統A有3項功能涉及用戶，即輸入、輸出和查詢；有一項功能是與系統B的接口。這4

9、項功能都是跨越邊界的，稱其為外部功能。在應用系統A中，內部文件的邏輯關系都未超出邊界，屬于內部功能。13.2 項目估算（1）外部輸入。外部輸入處理那些進入應用系統邊界的數據或是控制信息。經特定的邏輯處理后，形成內部邏輯文件。 （2）外部輸出。外部輸出處理離開應用系統邊界的數據或控制信息。 （3）內部邏輯文件。內部邏輯文件是用戶可識別的邏輯相關數據或控制信息組，它可在應用系統邊界之內使用。內部邏輯文件代表應用系統可支持的數據存儲需求。（4）外部接口文件。外部接口文件是用戶可識別的邏輯相關數據或控制信息構成的集合，該控制信息為應用系統所使用卻被另一應用系統所支持。外部接口文件代表應用系統外部支持的

10、數據存儲需求。 13.2 項目估算（5）外部查詢。外部查詢是唯一的輸入/輸出組合，它為實現即時輸出引起所需數據的檢索，代表了應用系統查詢處理的需求。2功能復雜性 軟件項目每類功能的復雜程度可能各不相同，為表明功能復雜性的差別，將其分為簡單的、中等的和復雜的3個等級。同時為表示其差異程度，分別給予不同的影響參數。下表列出了功能復雜性的影響參數值。 13.2 項目估算3未調節(jié)功能點 某一個軟件，只要我們能夠從規(guī)格說明中得到了以上5種功能度的各級復雜性功能點的個數C，不難計算出未調節(jié)功能點的值。13.2 項目估算其中：i代表功能度類型號；i=1，2，5； j代表復雜性的等級；j1，2，3； ij是第

11、i類功能度和第j級復雜性的影響參數，即上表 中第i行，第j列的參數值； Cij是第i類功能度和第j級復雜度功能點的個數。 4調節(jié)因子 任何軟件都會有其自身特性，在考慮其各種自身特性時，從以下兩個方面分解功能點計算的調節(jié)因子。（1）影響因子。經過對各類軟件的分析，綜合出以下14個 類型的影響因子：13.2 項目估算數據通信。分布數據處理。性能目標。系統配置要求。事務率。聯機數據錄入。最終用戶效率。聯機更新。復雜的處理邏輯?？蓮陀眯浴?易安裝性。 易操作性。 多工作場所。 設施變更。（2）影響級。上述影響因子對軟件功能度的影響有多大必須加以區(qū)分，于是將影響因子的影響程度分為6級，即 0級 無影響

12、1級 微小影響 2級 輕度影響 3級 中度影響 4級 顯著影響 5級 重大影響 綜合考慮14類影響因子的影響度N，應是將14種影響疊加起來，其值必定為070（145）。由此得到復雜度調節(jié)因子（complexity adjustment factor，CAF） CAF=0.65+0.01N其值應在0.651.35，其中基本調節(jié)常數是0.65，可見最大的調節(jié)量為35%。 13.2 項目估算5交付功能點 經過調節(jié)因子調節(jié)后的功能點值被稱為交付功能點（delivered function point，DFP） DFP=CAFUFP6交付功能點與軟件規(guī)模 一些研究成果表明，上述計算出的功能點的值可以代表

13、軟件的規(guī)模，也可作為估算成本的依據。軟件的規(guī)?？捎媒桓兜脑创a行數（delivered lines of code，DLOC）來表示。功能點與DLOC的對應關系如下表所示。例如 1 DFP相當于105 DLOC（COBOL程序）； 1 DFP相當于128 DLOC（C程序）。13.2 項目估算7功能點方法的優(yōu)點（1）DFP只與由規(guī)格說明得到的信息相關，而交付代碼的行數若不通過功能點計算是不能直接從規(guī)格說明中得到的。（2）DFP與實現軟件的語言無關。13.2 項目估算8功能點方法的不足之處（1）針對需求規(guī)格說明進行分析時，主觀因素難以完全排除，這包括： 對于規(guī)格說明，每人可能有不同的解釋； 對于

14、功能度的復雜性估計也可能因人而異； CAF計算時會有主觀因素。（2）非數據處理問題，如實時軟件、系統軟件、科學計算軟件等功能點的上述計算方法并不適用。（3）DFP的計算目前尚不能借助工具自動完成。 13.2 項目估算9功能點方法計算實例 某銀行的一個信息系統正在運行，其需求規(guī)格說明如下圖所示。 為表明對該系統需求規(guī)格說明的分析過程，對上圖中各類功能加了下畫線。現將各項功能分類列出。13.2 項目估算（1）外部輸入 增加新客戶； 刪除客戶； 存款業(yè)務； 提款業(yè)務； 給出透支報告的要求。（2）外部輸出 透支的警告信息； 透支客戶報告。（3）外部查詢 客戶查詢存款余額。（4）內部文件 客戶文件。 注

15、意，該例中沒有出現和其他應用系統的接口，并且假定以上功能均為簡單的復雜性。因此，未調節(jié)功能點 UFP=35+42+31+71=33 再來計算調節(jié)因子。根據本系統的規(guī)格先來選取各個影響因子的影響級，經分析影響因子取值如下表所示。13.2 項目估算因此，14類影響因子構成的影響度為 N=3+3+3+2+4+5+4+4+1+0+0+1+0+0=30于是復雜度調節(jié)因子為CAF0.65+0.0130=0.95最后，可算出交付的功能點值為DFP=0.9533=31.3513.2 項目估算 1專家判定Delphi方法 專家判定技術就是由多位專家進行成本估算，取得多個估算值。有多種方法把這些估算值合成一個估算

16、值，Read公司提出了Delphi技術，作為統一專家意見的方法?？傻玫綐O為準確的估算值。標準Delphi技術的步驟如下。 組織者發(fā)給每位專家一份軟件系統的規(guī)格說明書（略去名稱和單位）和一張記錄估算值的表格，請他們進行估算。 專家詳細研究軟件規(guī)格說明書的內容，然后組織者召集小組會議，在會上，專家們與組織者一起對估算問題進行討論。 13.2 項目估算軟件開發(fā)成本估算 各位專家對該軟件提出3個軟件規(guī)模的估算值，即ai該軟件可能的最小規(guī)模（最少源代碼行數）；mi該軟件最可能的規(guī)模（最可能的源代碼行數）；bi該軟件可能的最大規(guī)模（最多源代碼行數）。 無記名地填寫表格，并說明做此估算的理由。 組織者對各位

17、專家在表中填寫的估算值進行綜合和分類，做以下事情。 計算各位專家（序號為i，i=1，2，n）的估算期望值Ei和估算值的期望中值E。 對專家的估算結果進行分析。13.2 項目估算 組織者召集會議，請專家們對其估算值有很大差異之處進行討論。專家對此估算值另做一次估算。 在綜合專家估算結果的基礎上，組織專家再次無記名地填寫表格。 從步驟到步驟適當重復幾次，最終可獲得一個得到多數專家共識的軟件規(guī)模（源代碼行數）。 最后，通過與歷史資料進行類比，根據過去完成項目的規(guī)模和成本等信息，推算出該軟件每行源代碼所需成本。然后再乘以該軟件源代碼行數的估算值，得到該軟件的成本估算值。 13.2 項目估算2COCOM

18、O模型 Barry Boehm這位知名的軟件工程專家在其著作軟件工程經濟學中提出了他的軟件估算模型層次結構，稱為構造式成本模型COCOMO（COnstructive COst MOdel），也許這是在軟件界影響最為廣泛，也最為著名的估算模型。（1）3種類型的軟件 COCOMO是針對Boehm劃分的3種類型軟件進行估算的。 固有型（organic mode）項目。規(guī)模較小，較為簡單的項目，開發(fā)人員對項目有較好的理解和較為豐富的工作經驗，如傳熱系統中所用的熱分析程序。13.2 項目估算 嵌入型（embedded mode）項目。這類項目的開發(fā)工作緊密地與系統中的硬件、軟件和運行限制聯系在一起，如飛

19、機的飛行控制軟件。 半獨立性（semi-detached mode）項目。項目的性質介于上述兩個類型之間，其規(guī)模與復雜性均屬中等，如事務處理系統，數據庫管理系統等。（2）COCOMO的3級模型 基本COCOMO模型（basic model）。 該模型為靜態(tài)、單變量，以估算出的源代碼行數計算。 開發(fā)工作量：式中：E為工作量，單位為人月；KLOC為交付的千行代碼數。 13.2 項目估算開發(fā)期：式中：D為開發(fā)期，單位為月。 系數 基本COCOMO模型系數如下表所示。13.2 項目估算 中級COCOMO模型（intermediate）。 該模型除考慮源代碼行數外，還考慮調節(jié)因子（EAF），用其體現產品

20、、軟件、人員和項目等因素。 開發(fā)工作量： 系數 中級COCOMO模型系數如下表所示。13.2 項目估算 調節(jié)因子EAF（effort adjustment factor）。包含了4類15種屬性，其值為0.71.6。如下表所示。 高級COCOMO模型（advanced） 高級COCOMO模型除保留中級模型的因素外，還涉及軟件工程過程不同開發(fā)階段的影響，以及系統層、子系統層和模塊層的差別。 軟件可靠性在子系統層各開發(fā)階段有不同的調節(jié)因子，如下表所示。 13.2 項目估算13.2 項目估算1軟件風險 軟件工程項目的一系列活動要經歷各種過程，即軟件生存期過程。軟件項目的生存期過程正如人的一生一樣，不可

21、能百分之百地順利，而不遇到任何困難乃至危險。我們把軟件工程過程中可能出現的那些影響軟件目標實現，或是可能造成重大損失的事件稱為軟件風險。2風險的特點 在軟件工程項目過程實施中會遇到許多事件，但必須注意把軟件風險與其他事件區(qū)分開來。通常認為，風險具有以下特點。13.3 風險管理 什么是軟件風險 （1）可能發(fā)生的事件 風險是可能發(fā)生的事件，其發(fā)生的可能性用風險概率來描述。事件發(fā)生的可能性有多大，即風險概率是多少，在項目開始時應有初步的估計。（2）會給項目帶來損失的事件 風險的發(fā)生必定給項目造成損害，這當然是我們不希望出現的。（3）可能對其進行干預，以期減少損失 針對每一種風險，我們應弄清可能減少造

22、成損失或避免損失的程度。對風險加以控制，采取一些有效的措施來降低風險或是消除風險。13.3 風險管理 3風險分類 出于不同的考慮，可以有不同的風險分類。（1）依據危害性 從危害到軟件項目本身講，軟件風險可分為3類。 成本風險。成本風險是項目預算和開銷不夠準確造成 的。 績效風險。績效風險是系統不能提供全部或是某些預期 效益，或是不能實現預期的軟件需求。 進度風險。進度風險關系到項目進度或是項目達到指定 里程碑的不確定性。13.3 風險管理 （2）從風險涉及的范圍上考慮 從更大的范圍考慮，軟件風險還可分為3類。 項目風險。這種風險涉及預算、成本、進度、人員的招 聘和組織、資源的獲取，以及顧客和需

23、求等方面的問題。 技術風險。技術風險威脅著開發(fā)產品的質量和交付產品 的時間。技術風險會涉及設計方案、實現、接口、驗證， 以及維護等方面的問題。 商業(yè)風險。商業(yè)風險的發(fā)生會威脅開發(fā)軟件的生命力， 危及軟件項目和產品出路。常常出現的情況是： 13.3 風險管理 市場風險：開發(fā)了優(yōu)良的產品卻不為用戶真正需要，或是銷售人員不知怎么能送到用戶手中； 策略風險：開發(fā)的產品不能適應公司的整體商業(yè)策略； 管理風險：由于人員的變更或是公司工作中心的轉移，開發(fā)的產品失去了高層領導者的有力支持； 預算風險：沒有得到預算或人員方面的承諾。（3）其他分類 R.N.Charette給出了另一種風險的分類。 已知風險：在已

24、經對項目計劃、被開發(fā)軟件將在其中的 商業(yè)環(huán)境和技術環(huán)境，以及對其他的可靠信息來源做出仔13.3 風險管理 細評估以后能夠弄清的風險。所謂其他可靠信息來源可能是不現實的交付日期、缺少文檔化的需求或軟件范圍及不良的開發(fā)環(huán)境等。 可預知風險：根據以往項目的經驗可以推斷的風險，如人員調動、與顧客溝通有障礙、在為客戶作維護服務時人員工作積極性不高等。 不可預知風險：事先完全無法預料，好像是在開玩笑一樣，風險竟然突如其來。13.3 風險管理 如同軟件配置管理力圖把變更造成的影響降到最小一樣，風險管理力圖把風險帶來的影響，或造成的損失減少到最小。 1風險管理的目標和策略（1）目標。風險管理包括兩個重要的目標

25、： 識別風險。 采取措施，把風險造成的影響降低到最小。 識別風險是要找出可能的風險，對其進行分析、評估，并進一步對這些風險排序，以突出最為險惡的風險。 13.3 風險管理 風險管理的任務 （2）策略。降低風險危害的策略可能包括： 回避風險，如改變項目的某些功能或性能需求使風險不可能發(fā)生； 轉移風險，把風險轉移到其他系統，或是借助購買保險，將經濟損失轉移，從而化險為夷； 承受風險，接受風險，但將風險損失控制在項目資源可承受的范圍之內。2風險管理活動 為達到上述風險管理的目標，必須使風險管理圍繞風險評估和風險控制開展活動。風險管理活動及相關子活動如下圖所示。以下兩小節(jié)將對風險評估和風險控制分別加以

26、說明。13.3 風險管理 13.3 風險管理 風險評估的目標是認識可能的風險，它是風險控制的前提。風險評估通常包括：風險識別、風險分析和風險排序3個方面的內容。需要注意的是，在軟件工程項目的全過程中，風險評估可能不止進行一次。隨著各方面條件的變化，如有必要，在項目進行中可能需要進行再評估或是修改評估。1風險識別 就某個特定的軟件工程項目來說，從項目的具體情況出發(fā)，列舉出可能出現的風險，真正弄清每一可能風險的情況是風險識別的主要任務。風險識別的方法有：檢查單、判定 風險評估13.3 風險管理 驅動分析、假設分析、分解等。 檢查單（checklist）是識別風險的有力工具。它是將檢查單中所列舉的各

27、種風險，對照即將開發(fā)的軟件項目，逐一加以甄別，判定檢查單中哪些風險在該項目中可能發(fā)生。所謂分解是將一個大的項目劃分成若干明確定義的部分，然后對每個部分進行分析，看看各部分的可能風險是什么。有許多軟件項目的實際情況是，20%的模塊會引發(fā)出80%的項目問題。分解將有助于識別這些模塊的風險。 總之，風險識別時要弄清在項目中可能發(fā)生，但并不希望發(fā)生的事件，也即列舉出一些可能出現的“意外”事件，以便引起我們的重視，做到“有備無患”。13.3 風險管理 2風險分析 風險識別以后需要弄清楚已識別的風險可能何時何處發(fā)生，發(fā)生了會怎么樣。風險分析的任務是分析每個風險可能造成的影響，給出風險大小的量值。進行分析可

28、以借助一些已有的模型，但也并非所有巳列出的風險都可借助模型進行分析，因此，常常采用的是主觀分析。如果將成本模型用于成本估算和進度計劃估算，那么該模型便可用來評估成本風險和進度計劃風險。 風險分析的其他方法還包括：研究各種可能判定的概率和結果（判定分析）；理解任務取決于判定關鍵活動以及不能13.3 風險管理 及時完成這些任務的概率或成本（網絡分析）；有關各種質量因子，如可靠性和可用性的風險（質量因子分析）；以及如果對系統的性能有嚴格限制，早期借助于模擬等手段進行性能評估（性能分析）。3風險排序 識別出風險，并對其進行了分析將使我們初步弄清可能妨礙達到項目目標的危險事件，然而各種風險的后果會有很大

29、的差別，我們必須對其加以區(qū)別，以便把管理者的目光集中到最高風險的事件上。 13.3 風險管理 （1）風險概率。風險概率指的是風險事件出現的可能性，我們把各種概率值的風險劃分為3類：低概率風險、中概率風險和高概率風險。3類風險的概率取值按右表劃分。 （2）風險影響。風險影響的大小需要加以度量，如可以用損失的金額數來衡量。但為了簡單和直觀，可以把風險影響分為4個等級，并按1到10來賦值。如右表所示。13.3 風險管理 （3）風險排序的步驟 對已識別和分析了的風險估計概率的類別。 評估每個風險對項目的影響級。 風險排序應根據該項目各有關風險的概率和風險影響。 針對排序列在前位的幾個風險采取緩解措施和

30、跟蹤措施。（4）風險顯露（risk exposure） 風險顯露計算。有時需要精確地進行風險排序，這就要求針對每個風險對項目的威脅究竟有多大，做出量化的評定。風險對項目威脅的大小可用風險顯露來表示，它既和風險概率有關，也和風險發(fā)生造成損失的大小有關。于是有13.3 風險管理 RE（R）=Prob（R）Loss（R）式中：RE（R）是風險R的發(fā)生可能給項目造成的損失； Prob（R）是風險R發(fā)生的概率； Loss（R）是風險R如果發(fā)生會造成的損失。 風險顯露計算實例。這里以回歸測試工作為例，討論風險顯露的計算。 所謂回歸測試是軟件測試中的一種特定的測試。在軟件測試發(fā)現問題以后加以糾正，但糾正究竟

31、做得怎么樣是很值得重視的，必須保證糾正沒有帶來新的問題。為防止出現這些情況，原則上應該遵循回歸測試的要求，即只要改過了的程序就必須重新進行測試，否則會有誤改的風險。 13.3 風險管理 右圖為是否進行回歸測試共6種可能事件的風險顯露計算。圖中對6種可能事件分別列出了其概率值P及事件出現會造成的損失L，圖的右部則是按前述公式RE=ProbLoss計算出的風險顯露。在將前3種事件和后3種事件的風險顯露分別求和得到的數值（圖的最右端）后，便可得出結論：不做回歸測試要比做回歸測試可能給項目造成的損失要大得多。顯然，回歸測試是十分必要的。13.3 風險管理 13.3 風險管理 風險控制是由項目管理人員為

32、減輕風險造成危害要采用的一些主動措施。我們無法消除所有的風險，只能借助采取的措施，以人們可接受的方式處理有害結果，從而減輕風險，使風險損失降低到最小。 風險管理通常是從風險管理策劃開始，繼而實施風險計劃（或稱風險化解）和風險監(jiān)控。1風險管理策劃 風險管理策劃是要針對每個已經過識別和分析認為應該受風險控制控的風險制定風險管理計劃。按Boehm的意見，風險管理計劃主要包括以下5個方面。 該項風險為什么重要，為什么一定要管理。 風險管理應該能夠提供什么以及什么時候提供。 實施這些風險管理活動的責任人是誰。 風險怎么能夠得到減輕，該采取什么措施。 需要什么資源。 策劃風險管理的一個明顯的策略是風險回避

33、，就是采取措施回避風險。另外，也可采用有效的措施來減輕風險，對于那些無法回避的風險則應設法降低風險變?yōu)楝F實的概率，或是把風險發(fā)生造成的損失降低。 13.3 風險管理 2風險化解 風險化解是要實際消除風險或是減輕風險。實施風險管理計劃從根本上講就是將風險化解，如若計劃采用風險回避，那就要開展若干回避風險的活動。 為了幫助選擇風險減輕的方法，必須考慮減輕風險的成本。我們把風險顯露的損失差與風險減輕成本的比稱為風險杠桿（risk leverage），即 顯然，如果風險杠桿值不足以支持所采用的風險減輕的措施，那就要尋求更為低成本且更為高效的風險減輕方法。13.3 風險管理 有時可以選擇開發(fā)過程來減輕風

34、險，如開發(fā)原型可以有助于理解需求和設計，從而減輕風險。 風險管理計劃中記載了所做出的決策，它可讓顧客和開發(fā)組來審查可能發(fā)生的問題如何避免，以及這些問題一旦出現，該如何應對。隨著項目的進展，我們要隨時予以監(jiān)控，定期地對風險進行再評估，包括其發(fā)生的概率及可能造成的影響。13.3 風險管理 13.3 風險管理 3風險監(jiān)控（1）隨時監(jiān)控的必要性 由于風險是一些概率事件，它經常依賴于外部因素。在外部因素改變以后，風險構成的威脅可能和以前的評估有很大的差別。顯然，對風險的理解也要隨時間改變，進而所采取的風險化解措施可能影響著對風險的認識。（2）跟蹤監(jiān)控 上述的風險動態(tài)特性表明，不應把項目的風險看成是靜止不

35、動的。必須定期地對風險進行重新評估，并且除去要監(jiān)控那些已策劃的風險化解措施的實施情況外，需要對整個項目風險怎樣認識作定期的重新考察。 借鑒大量項目實踐中獲得的風險管理經驗和教訓，以下給出若干有益的建議。（1）要承認風險是客觀存在的，不可能完全避免。（2）對風險的認識最好組織開放式的討論，這樣做本身就能夠提高認識，降低風險的影響。（3）獎勵那些防止風險發(fā)生的人，不要只是懲罰和處分造成風險的人。（4）不應僅僅關注易于處理的風險。（5）不要試圖同時管理過多的風險。做好風險管理的建議 13.3 風險管理 （6）要記錄風險的情況。（7）把風險管理納入項目管理。（8）初期階段不必過分強調量化管理。（9）不

36、應追求實施風險管理的成本效益比。（10）記住，風險計劃本身又可能帶來新的風險，也可能會提高產品的成本。（11）回避風險應看成是最后的手段，采取時必須十分謹慎。（12）在組織級上采用風險數據庫，以便于項目之間借鑒風險數據。13.3 風險管理 1值得重視的現象 軟件項目能否按計劃的時間完成，及時提交產品是項目管理的一個重要課題。我們都希望按計劃及時完成，但項目未能按預期的進度提交產品，延誤工期的現象經常會出現。我們必須重視這一現象，分析其原因，并有針對性地采取措施。2制訂項目進度安排的條件 制訂項目進度安排計劃是為了實施，自然希望越準確，越符合實際越好，但是怎樣才能做到這一點，需要在這以前做些工作

37、，創(chuàng)造良好的條件，使得進度安排的確定是有13.4 進度管理進度控制問題 根據的。這些條件包括以下7條：（1）項目分解。無論多么大、多么復雜的項目都必須首先將其劃分成能夠管理的若干活動和若干任務，并且往往這種分解是多個層次的。 （2）確定各部分之間的相互關系。劃分后的活動和任務按項目本身的要求，必定存在著一定的相互依賴關系，如誰先誰后，或是兩者應該并行互不依賴等。 （3）時間分配。為每項活動和任務分配需要的時間，如需要多少人天的工作量。13.4 進度管理（4）確認投入的工作量。應確認按項目要求的人力投入工作量在實際工作中能夠予以滿足，而不致出現某些工作階段人力投入不足的現象。（5）確定人員的責任

38、。（6）規(guī)定工作成果。任何分配的任務都應給出符合要求的工作成果，它應該是整個項目的一個組成部分。（7）規(guī)定里程碑。任何一項工作完成后需經過一定形式的檢驗，如經過評審或審核（批準）得到認可，被認為確已完成，表示一個里程碑已經完成。里程碑也被稱為基線。 13.4 進度管理 甘特圖（Gantt chart）是表示工作進度計劃以及工作實際進度情況最為簡明的圖示方法。甘特圖中橫坐標表示時間，以水平線段表示子任務的工作階段，可以為其命名。線段的起點和終點分別對應著該項子任務的開工時間和完成時間，線段的長度表示完成它所需的時間，有實線和虛線之分，一開始做出各項子任務的計劃時間，應該都以虛線表示。如下圖所示。

39、圖中A、B、C、D、E 5個子任務隨著時間的進展一條垂直于各條線段的縱線逐漸右移，它將掃過的虛線變成實線，表示應該完成的任務，縱線右邊的虛線是待完成的任務。13.4 進度管理甘特圖 上圖中我們可以清楚地看出各項子任務在時間對比上的關系。然而甘特圖無法表達多個子任務之間更為復雜的銜接關系。下圖給出了某項目甘特圖的實例，圖中可表明各項任務的責任人及計劃時間數和實際完成的時間數，似乎更為實用。 13.4 進度管理13.4 進度管理 為克服甘特圖的缺點，將甘特圖做了一些修改，形成了時標網狀圖（time scalar network），如右圖所示。圖中的任務以有向線段表示，其指向點表示任務間的銜接點，并

40、且都給予編號，可以顯示出各子任務間的依賴關系。它顯示出比甘特圖具有優(yōu)越性。13.4 進度管理時標網狀圖 活動賦值與復審方法（program evaluation and review techique，PERT）也稱網絡圖方法，或簡稱PERT圖方法，它的另一名稱是關鍵路徑法（critical path method，CPM）。 PERT圖中以有向的箭頭作為邊表示子任務，它是有名稱（即子任務名）、有長度（即完成此項子任務所需的時間）的向量；以有編號的圓圈作為結點，它應該是子任務向量的始發(fā)點或指向點。由若干條邊和若干個結點構成了網狀圖，于是我們可以沿相互銜接的子任務形成的路徑，進行路徑長度的計算、

41、比較和分析，從而實現項目工期的控制。 13.4 進度管理PERT圖 我們先來看一個軟件開發(fā)實例。假定某一開發(fā)項目，進入編碼階段以后，考慮如何安排3個模塊A、B、C的開發(fā)工作。若A為一公共模塊，模塊B和C的測試有賴于A的調試通過。模塊C是利用現成的已開發(fā)模塊，對它需要看懂后，加以局部的修改。直到B和C做集成測試為止。這些工作步驟按以下網狀圖來安排。 13.4 進度管理 把前面甘特圖和時標網狀圖的例子畫成PERT圖，如下圖所示。讓我們對它做進一步分析。在每個結點圓圈附近的方框內有兩個數字，表示的是從起點算起該結點最早啟動時間和最遲啟動時間。13.4 進度管理 以結點5為例，從起始結點到達結點5有兩

42、條路經：0125，所用時間為9周；另一路徑是0345，所用時間為11周。由于子任務E2要求A3和E1都完成以后才開始，即使由前一路徑已先期到達5號結點，E2也不能開始，必須再等2周，E1到達后，E2才能開始，因此，5號結點附近的上方框內記為11（而不是9），這一數字表明該結點的最早啟動時間。其他有多個箭頭指向的結點均有類似情況，如結點7和8。另一方面，從終點逆向推進，在不影響任務進度的條件下，可得到各結點的最遲啟動時間。以結點3為例：沿路徑8543倒推至結點3應為5周啟動（15343=5）；但沿路徑873則應4周啟動13.4 進度管理（1583=4），因此，結點3最遲啟動時間為4周，在該結點附

43、近的下方的框內記為4（而不是5）。依此方法給每個結點的上下方框內均添入時間。我們特別注意到：0、3、7、8這四個結點的上下框內數字相同，這表明在這些結點上沒有停留的動機時間，這些結點構成的路徑所用時間是任務完成的最短時間，稱此路徑為關鍵路徑。其他結點上兩個數字不等，其差值為在此結點的機動時間。顯然，嚴格控制好關鍵路徑上各子任務的工期就能保證整個項目如期完成，不致延誤。 在組織較為復雜的任務時，或是需要對特定的子任務進一步作更為詳細的計劃時，我們可以使用分層的PERT圖。如13.4 進度管理下圖所示，在父圖No.0上的子任務P和Q均已分解出對應的兩個子圖：No.1和No.2。13.4 進度管理

44、軟件需求在軟件產品的整個生存期中占有重要位置，它是軟件工程項目的依據和出發(fā)點，無論是軟件的開發(fā)還是軟件的維護都是以軟件需求作為前提的。為了順利地提供高質量的軟件產品，依開發(fā)人員的觀點，軟件需求最好是清晰、正確、穩(wěn)定的。然而，用戶在開發(fā)過程中提出需求變更不可能完全避免。這就要求軟件人員能及時解決變更需求給開發(fā)工作帶來的沖擊，調整變更前已完成的那部分工作，使最終拿出的軟件產品滿足變更后的用戶需求。 需求管理正是要解決對于軟件人員來說十分棘手的上述問題。解決好需求管理問題是不成熟的軟件組織走向成熟邁出的第1步。 13.5 需求管理1系統和系統需求分配 （1）系統。通?？紤]的系統是指基于計算機的系統或

45、計算機控制的系統，它是在計算機控制下完成特定功能的系統，如航空管制系統生產控制系統等。（2）系統需求分配。系統完成的職能應由系統需求體現，而系統的需求通常是由用戶提出的。這里“用戶” 可能是客戶，也可能是最終用戶。而客戶可以是代理商，在其背后有許多最終用戶；還可以廣泛地被解釋為系統工程組、銷售組等。 13.5 需求管理系統需求與軟件需求 系統工程組面對用戶，負有開發(fā)系統的責任。系統工程組在從用戶那里取得系統需求以后，應將系統需求進行分解，也就是把已確定的系統需求分配給系統的各個組成部分。下圖為系統需求分配中各方面之間的相互關系。13.5 需求管理 顯然，軟件工程組負有開發(fā)系統中軟件部分的任務。

46、可以從系統工程組那里得到“分配給軟件的系統需求” ，在對其分析和研究以后，便得到軟件開發(fā)的依據軟件需求。 下面給出一個汽車限速系統ACCS需求分配的實例，如下圖所示。該系統的職能是當汽車速度超出預定的范圍時，由計算機硬件、軟件及相關機構加以控制。圖13-14給出了汽車限速系統的需求分配，其中，系統的需求是使汽車保持在預期車速的2km/h范圍內行駛。在將此系統需求分解以后，分配給硬件的系統需求是，要使車速在規(guī)定的精確度13.5 需求管理1.5km/h范圍之內。分配給軟件的系統需求是，在車速超出預定車速0.5km/h時，給硬件加速或減速的命令。 13.5 需求管理汽車限速系統ACCS的需求分配 2

47、軟件需求（1）軟件需求定義 軟件需求是用戶為解決某個問題或是為實現某個目標，要求軟件必須滿足的條件或能力。軟件需求可能由分配給軟件的需求得到，也可能由客戶或最終用戶提出。軟件需求的3個層次如上圖所示。 業(yè)務需求：客戶對軟件的高層目標要求。 用戶需求： 用戶使用軟件必須達到的要求和完成的任務； 通常在用況（use case）或場景（scenario）中加以說明。13.5 需求管理 功能和非功能需求：規(guī)定了開發(fā)人員必須實現的需求，它的實現將滿足上述業(yè)務需求和用戶需求。通常以需求規(guī)格說明（requirement specification）的形式加以詳盡描述。非功能需求包括以下兩種。 過程需求：交付

48、需求、實現需求、遵循的標準。 外部需求：互操作性、倫理性、機密性、安全性等。（2）質量功能展開 質量功能展開（quality function development，QFD）是將客戶的要求轉化為軟件技術需求的質量管理方法，其目標在于使軟件工程過程最大程度地讓客戶滿意。該方法強調軟件開發(fā)者必須充分理解，究竟什么需求和功能是對客戶最13.5 需求管理有價值的，然后通過工程過程將其展開和實現。 QFD將客戶的需求分為3類，這3類表明了客戶需求的不同層次。 常規(guī)需求：客戶明確提出的需求。 期望需求：一些隱含而未被客戶明確提出的需求。如果軟件開發(fā)組弄清了是那些，并且在產品中得到實現，客戶就會欣然接受；

49、但若相反，產品中并未實現隱含的期望，客戶就會表現出很大的不滿，也可稱此為客戶的潛在需求。 興奮需求：客戶完全沒有想到的需求，如果產品中未將其實現，客戶并不抱怨；但若真的實現了，就會超出客戶的想象之外，他們會感到十分驚訝和非常滿意。 13.5 需求管理 需求工程是系統工程或軟件工程中解決需求問題的一個嶄新領域。其目標在于使工程得到的產品能夠準確、真實地體現客戶的需求，令客戶滿意。它包括需求開發(fā)與需求管理。如下圖所示。 13.5 需求管理需求工程 需求工程的構成 需求開發(fā)與需求管理 1需求開發(fā) 需求開發(fā)是在開發(fā)人員與客戶雙方密切配合下完成的，任務是得到需求規(guī)格說明。需求開發(fā)工作包括以下4個方面。（

50、1）獲取需求。開發(fā)人員首先應確定產品的客戶群或產品的服務對象，全面了解開發(fā)工作面對的實際業(yè)務和業(yè)務需求。（2）分析需求。開發(fā)人員分析用戶提供的需求信息，區(qū)分業(yè)務需求、功能需求、非功能需求和質量屬性等，并且弄清每項需求的必要性。（3）定義需求。確定下來的需求必須以正式文檔形式表達，這就是需求規(guī)格說明。13.5 需求管理（4）驗證需求。需求規(guī)格說明能否符合上述要求，需要經過評審。當然，評審后要對發(fā)現的問題做出必要的修改。 2需求管理 需求管理是要解決在需求開發(fā)之后，也即得到需求規(guī)格說明之后，在后繼的開發(fā)工作過程中用戶提出了新的需求或變更了原定的需求，在這種情況下開發(fā)工作應如何處理。 需求管理會涉及

51、：（1）變更控制；（2）需求狀態(tài)跟蹤；（3）需求跟蹤；（4）需求文檔版本控制。 13.5 需求管理1需求變更難于完全避免 系統需求或軟件需求往往在開發(fā)工程中發(fā)生變更，提出變更有可能在開發(fā)的任何階段。通常，隨著時間的推移，開發(fā)工作進一步展開，人們對問題本身和對用戶的真正需求有了更為深入和透徹的了解，這時會發(fā)現基于對問題初始理解而提出和制定的初始需求有著不完善或不妥當之處，于是提出需求變更，這一現象并不少見。它是人對事物的認知規(guī)律決定的，要想完全避免是不可能的。需求變更 13.5 需求管理2需求變更原因分析 引發(fā)需求變更可能有多種因素。（1）單純的用戶因素。（2）市場形勢變化引發(fā)的需求變更。（3）

52、系統因素：在系統內部，如計算機硬件、系統軟件或數據等的變更要求軟件與其相適應。（4）工作環(huán)境因素：與軟件運行相關的工作制度或法規(guī)、政策的變更，或是業(yè)務要求變更導致的需求變更。（5）需求開發(fā)工作缺陷，可能有兩種情況： 需求分析、定義和評審工作不夠充分。 需求開發(fā)中開發(fā)人員與用戶溝通得不夠充分。13.5 需求管理3需求變更對軟件開發(fā)工作的影響（1）使得變更前的開發(fā)工作和成果失效。（2）使得返工成為不得不采取的對策。（3）勢必帶來軟件開發(fā)計劃的相應變更，開發(fā)成本的相應增加和開發(fā)工作量及資源投入的追加。4需求變更失控可能導致的后果 在軟件開發(fā)過程中出現了需求的變更，如果忽視了對它的控制，沒有針對上述變

53、更造成的影響及時地采取有效措施，便可能導致開發(fā)出的產品不符合變更的需求，即得到的產品并不是用戶所需要的產品這樣的嚴重后果。 13.5 需求管理5降低需求變更風險的策略（1）在需求開發(fā)工作中要與客戶充分溝通 。（2）與用戶共同確定需求，認真聽取客戶意見，在雙方共同驗證確定了的需求后均應簽字以示承諾，希望以此減少頻繁改變需求的可能。（3）開發(fā)組織和用戶雙方簽署的項目開發(fā)合同中應包括開發(fā)中對出現需求變更的應對條款。（4）如果項目自身具有需求不易確定的特點，在項目啟動時最好采用快速原型方法或螺旋模型，以便在確認需求的基礎上開發(fā)產品。13.5 需求管理（5）在項目開始時，如估計到需求可能有變，則可在開發(fā)

54、計劃中適當留有余地，以防變更需求造成的被動。（6）嚴格實施變更控制，使產品質量不致因需求變更受到影響。13.5 需求管理1需求變更控制要求（1）變更控制的策略 所有需求變更必須遵循需求變更控制規(guī)程實施變更。 需求變更提出后是否被接受應由專門的組織變更控制委員會審查決定。 不得以任何理由刪除和修改需求變更的原始文件。 應將已接受的需求變更通知到所有相關人員。 已接受的需求變更應能追溯到批準的變更請求。 對項目的需求賦予狀態(tài)屬性，以利于需求變更控制。 需求變更控制 13.5 需求管理（2）需求變更影響的控制 由于分配需求的變更導致軟件計劃、工作產品和活動的變更，因此對每一變更都應對其進行下述工作：

55、 識別； 評價； 風險分析； 編制文檔； 制訂計劃； 傳達給受影響的小組和人員； 跟蹤直至結束。 13.5 需求管理（3）變更控制的步驟 提出變更請求。 審理變更請求，進行變更影響評估，評估內容包括： 變更所需人力投入； 變更對原計劃安排的影響； 估計變更引起的成本增加。 批準變更請求。 取得用戶的認可。 修訂項目計劃。 實施變更。 驗證變更。 13.5 需求管理 需求變更流程如下圖所示。13.5 需求管理2需求變更控制實施（1）需求變更請求 內容 申請?zhí)枺鹤兏埱蟮捻樞蛱枴?變更說明：變更請求的概要描述。 變更類型：如合同變更、功能變更或性能變更等。 影響分析：扼要說明變更涉及的工作產品、工

56、作量和進度安排等。 變更請求狀態(tài)：提出變更請求時正處在什么開發(fā)階段或正做什么工作。 變更請求日期。 13.5 需求管理 需求變更請求實例 如下表所示。13.5 需求管理（2）需求控制流 需求狀態(tài)。1）軟件需求在需求開發(fā)結束以后被確定下來，在其后繼階段開發(fā)工作中將逐步展開，加以實現。2）在不同的開發(fā)階段軟件需求以不同的形式進行著狀態(tài)的演變。 需求階段：從獲取的需求到定義的需求。 建議階段：制訂出項目計劃以后演化為承諾的需求。 設計階段：設計工作完成并經驗收后成為設計的需求。13.5 需求管理 編碼階段：完成編碼和單元測試后成為實現的需求。 測試階段：完成確認測試后成為完成的需求。 3）下圖為生存

57、期各階段軟件需求狀態(tài)的演變。 演變。 下圖表明了生存期各階段中需求狀態(tài)的控制流。13.5 需求管理1需求可追溯性與需求變更控制 隨著開發(fā)工作的進展，需求狀態(tài)在各階段上也在演變著。如果將籠統的需求狀態(tài)演變概念加以具體化，考慮某一項特定的需求，它也必然隨著開發(fā)工作的進展而逐步擴展和演化。例如，某項需求A，在設計階段完成后得到設計A，編程后得到程序模塊A，測試中使用了測試用例A1，A2，An等。沿著這個線索，各個開發(fā)階段的工作產品之間存在的繼承關系是清晰的。如果以某種方式（例如以下給出的可追溯矩陣）對其做出確切的表達，那么需求變更無論出現在任何階段，都能沿著這一線索進行無遺漏的追蹤，對相關部分實施修

58、正和調整，最終做到變更控制。 可追溯性管理 13.5 需求管理2可追溯性管理的目標 實施需求可追溯性管理應使每一項需求均能追溯到：對應的設計、實現該項需求的代碼以及測試此項實現的用例。這樣便可做到確保軟件產品滿足所有需求，并已測試了所有需求，從而使表現前后繼承關系的脈絡清晰可見。3兩類不同的追溯（1）向前追溯：沿生存期從需求跟蹤到設計、編碼、測試等后繼階段輸出工作產品的相關元素。（2）向后追溯：從各階段工作產品的元素反向追溯，直至追溯到初始需求。13.5 需求管理4可追溯矩陣 下表所示為一個追溯矩陣的實例（表中只含一項需求）。（1）說明 需求號：需求規(guī)格說明中將每項需求編號，此為該項需求號碼。

59、 需求描述：扼要給出該項需求的說明，可以是關鍵字，也可以是需求規(guī)格說明的摘錄，但應是簡明的描述。13.5 需求管理 概要設計文檔索引號：概要設計規(guī)格說明對應此項需求部分的章節(jié)號。 對應的設計：簡要說明與此項需求對應的設計。 實現：對應的程序名或程序模塊名，表中指出了由兩個模塊實現此項需求。：3級測試中使用了這些編號的測試用例（編號與測試用例的對應表暫略）。（2）矩陣的作用 完整的追溯矩陣應將所有的需求分項一一列出，這樣做可防止遺漏，避免因未實現某項需求，或因需求出現變更未及時修改相關的部分而造成產品缺陷或造成返工。13.5 需求管理 可為評審提供方便，矩陣有利于判斷全面實現需求的情況。 在需求

60、變更時便于進行變更影響追蹤、分析和檢查。（3）矩陣的建立與維護 追溯矩陣初建時只有左邊兩欄和，因為此時尚屬需求階段，隨后開發(fā)工作進入設計階段，在設計評審后可填入和兩欄；接著在編碼完成及單元測試、集成測試和驗收測試后，分別填入、和各欄內容。 按此矩陣的要求，項目各工作產品的重要部分，包括需求、設計、程序和測試用例均應有編號作標識，以利于檢索追蹤。 13.5 需求管理（4）矩陣的應用 追溯矩陣主要應用在兩個方面。 完整性檢驗 考察有無需求遺漏的情況。要求矩陣中需求號與需求規(guī)格說明中的需求編號一一對應，如有遺漏可非常容易地發(fā)現。 有無冗余代碼?？蓮木仃囍锌吹绞欠衩總€程序單元、類或其他元素均已列入。