《軟件工程基礎(chǔ)》第13章 軟件項(xiàng)目管理

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

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

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

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

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

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

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

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

9、項(xiàng)功能都是跨越邊界的，稱其為外部功能。在應(yīng)用系統(tǒng)A中，內(nèi)部文件的邏輯關(guān)系都未超出邊界，屬于內(nèi)部功能。13.2 項(xiàng)目估算（1）外部輸入。外部輸入處理那些進(jìn)入應(yīng)用系統(tǒng)邊界的數(shù)據(jù)或是控制信息。經(jīng)特定的邏輯處理后，形成內(nèi)部邏輯文件。 （2）外部輸出。外部輸出處理離開(kāi)應(yīng)用系統(tǒng)邊界的數(shù)據(jù)或控制信息。 （3）內(nèi)部邏輯文件。內(nèi)部邏輯文件是用戶可識(shí)別的邏輯相關(guān)數(shù)據(jù)或控制信息組，它可在應(yīng)用系統(tǒng)邊界之內(nèi)使用。內(nèi)部邏輯文件代表應(yīng)用系統(tǒng)可支持的數(shù)據(jù)存儲(chǔ)需求。（4）外部接口文件。外部接口文件是用戶可識(shí)別的邏輯相關(guān)數(shù)據(jù)或控制信息構(gòu)成的集合，該控制信息為應(yīng)用系統(tǒng)所使用卻被另一應(yīng)用系統(tǒng)所支持。外部接口文件代表應(yīng)用系統(tǒng)外部支持的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38、。（6）規(guī)定工作成果。任何分配的任務(wù)都應(yīng)給出符合要求的工作成果，它應(yīng)該是整個(gè)項(xiàng)目的一個(gè)組成部分。（7）規(guī)定里程碑。任何一項(xiàng)工作完成后需經(jīng)過(guò)一定形式的檢驗(yàn)，如經(jīng)過(guò)評(píng)審或?qū)徍耍ㄅ鷾?zhǔn)）得到認(rèn)可，被認(rèn)為確已完成，表示一個(gè)里程碑已經(jīng)完成。里程碑也被稱為基線。 13.4 進(jìn)度管理 甘特圖（Gantt chart）是表示工作進(jìn)度計(jì)劃以及工作實(shí)際進(jìn)度情況最為簡(jiǎn)明的圖示方法。甘特圖中橫坐標(biāo)表示時(shí)間，以水平線段表示子任務(wù)的工作階段，可以為其命名。線段的起點(diǎn)和終點(diǎn)分別對(duì)應(yīng)著該項(xiàng)子任務(wù)的開(kāi)工時(shí)間和完成時(shí)間，線段的長(zhǎng)度表示完成它所需的時(shí)間，有實(shí)線和虛線之分，一開(kāi)始做出各項(xiàng)子任務(wù)的計(jì)劃時(shí)間，應(yīng)該都以虛線表示。如下圖所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

55、 識(shí)別； 評(píng)價(jià)； 風(fēng)險(xiǎn)分析； 編制文檔； 制訂計(jì)劃； 傳達(dá)給受影響的小組和人員； 跟蹤直至結(jié)束。 13.5 需求管理（3）變更控制的步驟 提出變更請(qǐng)求。 審理變更請(qǐng)求，進(jìn)行變更影響評(píng)估，評(píng)估內(nèi)容包括： 變更所需人力投入； 變更對(duì)原計(jì)劃安排的影響； 估計(jì)變更引起的成本增加。 批準(zhǔn)變更請(qǐng)求。 取得用戶的認(rèn)可。 修訂項(xiàng)目計(jì)劃。 實(shí)施變更。 驗(yàn)證變更。 13.5 需求管理 需求變更流程如下圖所示。13.5 需求管理2需求變更控制實(shí)施（1）需求變更請(qǐng)求 內(nèi)容 申請(qǐng)?zhí)枺鹤兏?qǐng)求的順序號(hào)。 變更說(shuō)明：變更請(qǐng)求的概要描述。 變更類型：如合同變更、功能變更或性能變更等。 影響分析：扼要說(shuō)明變更涉及的工作產(chǎn)品、工

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

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

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

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

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