第3章 軟件項目管理ppt課件

1、第三章 軟件工程管理工程管理的概念軟件工程度量軟件工程方案與估算風險分析和管理工程進度安排軟件質量保證軟件配置管理工程管理的譜系人員管理產(chǎn)品管理工程管理過程管理軟件工程管理項目參與者項目負責人軟件項目組協(xié)調通信問題軟件范圍問題分解確定軟件過程模型過程分解確定危險信息確定解決方案 軟件工程管理的目的、義務和內(nèi)容目的 為了使軟件工程可以在預定本錢、進度、質量的前提下順利完成，必需對軟件工程工程進展方案、組織、監(jiān)控和管理 義務制定軟件工程的實施方案和方案；對人員進展組織和分工；按照方案進度，以及本錢管理、風險管理、質量管理的要求進展軟件開發(fā)，完成軟件工程的各項要求和義務。 3.1.1 軟件度量軟件度

2、量的概念軟件規(guī)模度量軟件功能度量3.1 軟件工程度量軟件度量分類3.1.1.1 度量、估算度量 metrics度量具有數(shù)字特征，軟件工程范圍的度量是軟件開發(fā)過程、軟件資源或軟件產(chǎn)品簡單屬性的定量描畫。如，程序規(guī)模、操作符個數(shù)、程序中錯誤的個數(shù)等。估算 estimation對軟件產(chǎn)品、過程、資源進展預測估算可以采用閱歷公式、或參考歷史資料估算用于事前簽署合同、立項、制定任務方案等 軟件的外部屬性和內(nèi)部屬性外部屬性 軟件產(chǎn)品、過程、資源與環(huán)境的關系如，本錢、效益、勞動消費率、可靠性、可維護性內(nèi)部屬性 軟件產(chǎn)品、過程、資源、環(huán)境本身的屬性如，產(chǎn)品構造、模塊化程度、復雜性、程序長度等。產(chǎn)品-過程-資源

3、產(chǎn)品的內(nèi)部屬性程序代碼長度 程序功能 模塊化 重用性控制流 數(shù)據(jù)流 模塊耦合度與內(nèi)聚度 產(chǎn)品的外部屬性程序的可靠性 可用性 可維護性軟件的可了解性 有效性 可移植性 過程的內(nèi)部屬性 任務量 方案和進度 一段時間內(nèi)某類事件發(fā)生的次數(shù) 過程的外部屬性 本錢 可控制性 可察看性 穩(wěn)定性資源的內(nèi)部屬性 人 軟硬件環(huán)境 方法 閱歷資源的外部屬性 本錢 時間3.1.1.2 面向規(guī)模的度量代碼行數(shù) LOC或KLOC消費率 Pl=L/E 其中 L 軟件工程代碼行數(shù) E 軟件工程任務量人月 PM Pl 軟件工程消費率LOC/PM代碼出錯率 EQRl=Ne/L 其中 Ne 軟件工程的代碼錯誤數(shù) EQRl 每千行代

4、碼的錯誤數(shù)每行代碼平均本錢 Cl=S/L 其中 S 軟件工程總開銷元美圓 Cl軟件工程每行代碼的平均本錢文檔與代碼比 Dl=Pd/L 其中 Pd 軟件工程文檔頁數(shù) Dl 每千行代碼的平均文檔數(shù)例 軟件工程記錄項目工作量 PM成本萬美元代碼行kLOC文檔頁數(shù) Pd錯誤數(shù) Ne人數(shù) MAaa-012416.812.1365293Ccc-046244.027.21224865Fff-034331.420.21050646消費率：Pl=L/E=12.1kLoc/24PM=504Loc/PM出錯率：EQRl=Ne/L=29個/12.1kLoc=2.4個/kLoc平均本錢：Cl=S/L =168 000美

5、圓/12.1kLoc= 13.88美圓/Loc每千行代碼的平均文檔頁數(shù)：Dl=Pd/L=365Pd/ 12.1kLoc=30.16Pd/kLoc 規(guī)模度量的優(yōu)缺陷用軟件代碼行數(shù)估算軟件規(guī)模簡單易行。缺陷代碼行數(shù)的估算依賴于程序設計言語的功能和表達才干；采用代碼行估算方法會對設計精巧的軟件工程產(chǎn)生不利的影響；在軟件工程開發(fā)前或開發(fā)初期估算它的代碼行數(shù)非常困難；代碼行估算只適用于過程式程序設計言語，對非過程式的程序設計言語不太適用等等。 根據(jù)事務信息處置程序的根本功能定義的，在系統(tǒng)設計初期可以估算出軟件工程的規(guī)模 FP=CT*0.65+0.01*Fi 其中：CT按表3.1計算() Fi 是復雜性調

6、理值 Fi 取值 0,1,.,5 當 Fi = 0 時，表示 Fi 不起作用 Fi = 5 時，表示 Fi 作用最大3.1.1.3 面向功能的度量 表3.1 功能點度量丈量參數(shù) 值 權值用戶輸入數(shù) *4 用戶輸出數(shù) *5 用戶查詢數(shù) *4 文件數(shù) *7 外部界面數(shù) *7 CT 表3.1中的五個信息量按以下方式取值用戶輸入數(shù) 用戶為軟件提供的輸入?yún)?shù)個數(shù)用戶輸出數(shù) 軟件系統(tǒng)為用戶提供的輸出參數(shù)個數(shù)用戶查詢數(shù) 一個聯(lián)機輸入確定一次查詢，軟件以 聯(lián)機輸出的方式,實時地產(chǎn)生一個呼應文件數(shù) 統(tǒng)計邏輯的主文件個數(shù)外部界面數(shù) 統(tǒng)計一切機器可讀的界面，利用這些 界面可以將信息從一個系統(tǒng)傳送到另一 個系統(tǒng)用功能

7、點定義相應的概念消費率： Pf=FP/E 其中 Pf表示每人月完成的功能點數(shù)平均本錢：Ci=S/FP 其中 Ci表示每功能點的平均本錢文檔與功能點比：Di=Pd/FP 其中 Di表示每個功能點平均具有的文檔頁數(shù)代碼出錯率：EORi=Ne/FP 其中 EORi表示每個功能點的平均錯誤個數(shù) 面向功能的度量軟件規(guī)模的功能點度量沒有直接涉及軟件系統(tǒng)本身的算法復雜性。1986年Jones把軟件工程中的算法復雜性要素引入到功能點計算中來，為了防止混淆，我們把Albrecht定義的功能點稱為簡單功能點，用FPs表示，把Jones推行的功能點稱為功能點，用FP表示。推行的功能點包括計算機程序中用于各類問題求解

8、的算法要素，如求解線性代數(shù)方程組、遍歷二叉樹的各個結點、處置中斷等等。功能點計算仍用上面的公式,其中CT按表3.2計算。 表3.2 推行的功能點度量 丈量參數(shù) 值 權值用戶輸入數(shù) *4 用戶輸出數(shù) *5 用戶查詢數(shù) *4 文件數(shù) *7 外部界面數(shù) *7 算法 *3 CT 對普通的工程計算或事務處置軟件，用表3.1和表3.2兩種方法計算出來的FP值應該根本上一樣對于比較復雜的軟件系統(tǒng) FP比FPs的值高20%35% 面向功能的度量的優(yōu)缺陷優(yōu)點與程序設計言語無關，它不僅適用于過程式言語，也適用于非過程式的言語；軟件工程開發(fā)初期就能根本上確定系統(tǒng)的輸入、輸出等參數(shù)，功能點度量能用于軟件工程的開發(fā)初期

9、。缺陷它涉及到的客觀要素比較多，如各種權函數(shù)的取值；信息領域中的某些數(shù)據(jù)有時不容易采集；FP的值沒有直觀的物理意義。3.1.1.4 代碼行度量與功能點度量的比較代碼行度量依賴于程序設計言語，而功能點度量不依賴于程序設計言語。Albrecht和Jones等人對假設干軟件采用事后處置的方式分別統(tǒng)計出不同程序設計言語每個功能點與代碼行數(shù)的關系，用LOC/FP的平均值表示。表3.3闡明，一行Ada言語代碼的“功能平均是一行FORTRAN言語代碼“功能的1.4倍。一行四代言語代碼的“功能平均是一行傳統(tǒng)程序設計言語代碼“功能的3至5倍。 表3.3 各種言語的LOC/FP(平均值)程序設計言語 LOC/FP

10、(平均值)匯編言語 300COBOL 100FORTRAN 100Pascal 90Ada 70面向對象的言語 30四代言語(4GL) 20代碼生成器 153.1.2軟件復雜性度量1976年 T.J.McCabe McCabe度量法又稱環(huán)路復雜性度量,基于程序控制構造的軟件復雜性度量模型。程序控制構造圖 程序構造對應于有一個入口結點和一個出口結點的有向圖圖中每個結點對應一個語句或一個順序流程的程序代碼塊弧對應于程序中的轉移它基于一個程序模塊的程序圖中環(huán)路的個數(shù)，因此計算它先要畫出程序圖。程序圖是退化的程序流程圖。流程圖中每個處置都退化成一個結點，流線變成銜接不同結點的有向弧。McCabe度量法

11、 McCabe用程序控制構造圖的巡回秩數(shù)V(G)作為程序構造復雜性的度量 V(G) = e-n+2 其中：e為構造圖的邊數(shù) n為構造圖的結點數(shù) 可以證明 V(G)等于構造圖中有界或無界的封鎖區(qū)域個數(shù)例3.1計算程序控制構造的V(G)值E = 1 E = 3N = 2 N = 3V = 1 V = 2計算程序控制構造的V(G)值E = 4 E = 3N = 4 N = 3V = 2 V = 2計算程序控制構造的V(G)值E = 6N = 5V = 3例3.1 計算如下圖程序控制構造圖的V(G)值。 (a) e=1,n=2,v=1; (b) e=3,n=3,v=2; (c) e=4,n=4,v=2

12、； (d) e=3,n=3,v=2; (e) e=6,n=5,v=3.例如：在前面的例示中,n11，m13，V(G)mnp131113.p1McCabe建議把V(G)作為模塊規(guī)模的定量目的，一個模塊V(G)的值不要大于10 當V(G)10時，模塊內(nèi)部構培育會變得復雜，給編碼和測試帶來困難。這種度量的缺陷是： 對于不同種類的控制流的復雜性不能區(qū)分 簡單IF語句與循環(huán)語句的復雜性同等對待 嵌套IF語句與簡單CASE語句的復雜性是一樣的 模塊間接口當成一個簡單分支一樣處置 一個具有1000行的順序程序與一行語句的復雜性一樣3.2 軟件工程方案與估算3.2.1 軟件工程方案 軟件工程管理人員在開發(fā)任務

13、一開場需求進展定量估算。 軟件工程方案的目的是提供一個能使工程管理人員對資源、本錢和進度做出合理估算的框架。 這些估算該當在軟件工程開場時的一個有限的時間段內(nèi)做出，并且隨著工程的進展定期進展更新。 軟件工程方案的目的 軟件的范圍軟件范圍包括功能、性能、限制、接口和可靠性。估算開場時，應對軟件的功能進展評價，對其進展適當?shù)募毣员闾峁└敿毜募毠?jié)。由于本錢和進度的估算都與功能有關，因此經(jīng)常采用某種程度的功能分解。性能的思索包括處置和呼應時間的需求。約束條件那么標識產(chǎn)品本錢、外部硬件、可用存儲或其它現(xiàn)有系統(tǒng)對軟件的限制。軟件與其它系統(tǒng)元素是相互作用的。要思索每個接口的性質和復雜性，以確定對開發(fā)資源

14、、本錢和進度的影響。軟件開發(fā)中的資源3.2.2 軟件工程估算常用的估算方法參照曾經(jīng)完成的類似工程估算待開發(fā)工程的本錢和任務量。將大的工程分解成假設干子工程，在估算出每個子工程本錢和任務量之后，再估算整個工程。將軟件工程按軟件生存周期分解，分別估算出軟件工程在軟件開發(fā)各個階段的任務量和本錢，然后再把這些任務量和本錢匯總估算整個工程。根據(jù)實驗或歷史數(shù)據(jù)給出軟件工程任務量或本錢的閱歷估算公式。四種方法可以同時、單獨或組合運用，以便取長補短，提高工程估算的精度和可靠性。 采用分解技術估算軟件工程應思索系統(tǒng)集成時需求的任務量。為了實現(xiàn)軟件工程估算，實際中開發(fā)了大量的軟件工程自動估算工具，用以支持軟件任務

15、量或本錢估算。分解技術采用分而治之的戰(zhàn)略進展軟件工程估算.將工程分解為假設干個主要的功能及相關的軟件工程活動,經(jīng)過逐漸求精的方式進展本錢及任務量估算。閱歷估算模型可用于補充分解技術自動估算工具實現(xiàn)一種或多種分解技術或閱歷模型，與人機交互結合，自動估算將是很好的選擇。3.2.2.1 代碼行、功能點和任務量估算軟件工程的規(guī)模是影響軟件工程本錢和任務量的重要要素。軟件工程代碼行和功能點估算是本錢和任務量估算的根底。采用上面的估算方法可以估算出LOC或FP的樂觀值a，悲觀值b和普通值m，然后根據(jù)以下加權公式計算出期望值 e=(a4mb)6 希望LOC或FP的值落在區(qū)間a,b之外的概率極小 當LOC或F

16、P的期望值估算出來之后，根據(jù)以前軟件工程開發(fā)的平均消費率LOC/PM或FP/PM就可以計算出任務量。如，軟件工程的規(guī)模估算為310FP，以前完成的軟件工程的消費率為5.5FP/PM，于是任務量估算為E=310/5.5=56PM。例 3.2 估算計算機輔助設計軟件工程將CAD工程按功能分解為七個子工程用戶界面和控制；二維幾何分析；三維幾何分析；數(shù)據(jù)庫管理；計算機圖形顯示；外設控制；設計分析。表3.4給出七個子工程代碼行的樂觀估計、悲觀計和普通估計值，然后計算出加權平均值。 估算計算機輔助設計軟件工程 分析七個子工程的規(guī)模復雜性和難度，參照以前開發(fā)類似工程的閱歷給出開發(fā)每行代碼的平均本錢，每月開發(fā)

17、的代碼行數(shù)。 用這兩組數(shù)據(jù)計算出七個子工程的開發(fā)本錢和任務量。 最后匯總的CAD軟件開發(fā)工程 規(guī)模為 33360 LOC 本錢為 656680 $ 任務量為 144.5 PM。再用這兩種方法分別估算軟件開發(fā)子工程在軟件工程各個階段的任務量，估算結果列入表3.5。兩種方法估算的任務量分別為144.5PM和152.5PM，相差5%左右。估算的本錢分別為656680$和708075$，相差7%左右。 兩種方法估算的任務量和本錢根本一致。 表3.4 代碼行和本錢、任務量估算 功能 樂觀 普通 悲觀 加權 $ LOC 本錢 任務量 LOC LOC LOC 平均 /LOC /PM (人月)用戶界面控制17

18、90 2400 2650 2340 14 315 32760 7.4 二維幾何分析4080 5200 7400 5380 20 220 107600 24.4三維幾何分析4600 6900 8600 6800 20 220 000 30.9數(shù)據(jù)庫管理 2900 3400 3600 3350 18 240 60300 13.9圖形顯示 3900 4900 6200 4950 22 200 108900 24.7外設控制 1990 2100 2450 2140 28 140 59920 15.2設計分析 6600 8500 9800 8400 18 300 151200 28.0總計 33360

19、656680 144.5 表3. 5任務量估算 功能 需求分析 設計 編碼 測試 總計用戶界面控制 1.0 2.0 0.5 3.5 7二維幾何分析 2.0 10.0 4.5 9.5 26三維幾何分析 2.5 12.0 6.0 11.0 31.5數(shù)據(jù)庫管理 2.0 6.0 3.0 4.0 15計算機圖形顯示 1.5 11.0 4.0 10.5 27外設控制 1.5 6.0 3.5 5.0 16設計分析 4.0 14.0 5.0 7.0 30總計(人月) 14.5 61 26.5 50.5 152.5 每人月本錢 5200 4800 4250 4500本錢() 75400 292800 11262

20、5 227250 708075 3.2.2.2 閱歷估算模型之一 CoCoMo模型計算機軟件的估算模型是根據(jù)以前完成工程的實踐數(shù)據(jù)導出的，用于軟件工程的方案階段。 模型是根據(jù)“從前的，“部分的數(shù)據(jù)得出的，估算模型不能夠完全適用于當前一切的軟件工程和全部開發(fā)環(huán)境。這些模型的計算結果僅供參考。 兩個常用的估算模型 CoCoMo模型 Putnam模型 CoCoMo模型1981年Boehm提出“構造性本錢模型(Constructive Cost Model)，簡稱CoCoMo模型。它是在靜態(tài)、單變量模型的根底上構造出來的。 CoCoMo模型分為根本、中間、詳細三個層次，分別用于軟件開發(fā)的三個不同階段。

21、根本CoCoMo模型 用于系統(tǒng)開發(fā)的初期，估算整個系統(tǒng)的任務量(包括軟件維護)和軟件開發(fā)所需求的時間。 中間CoCoMo模型 用于估算各個子系統(tǒng)的任務量和開發(fā)時間。 詳細CoCoMo模型 用于估算獨立的軟部件，如子系統(tǒng)內(nèi)部的各個模塊。 1 根本CoCoMo模型靜態(tài)、單變量模型 E = aLb (3-1) D = cEd (3-2)其中： E表示任務量，單位是人月(PM)。 D表示開發(fā)時間，單位是月(M)。 L是工程的代碼行估計值，單位是千行代碼 a,b,c,d是常數(shù)，取值如表3.6所示。 Boehm把軟件劃分為組織型、半獨立型和嵌入型三類，允許不同運用領域和復雜程度的軟件按照三類軟件的適用范圍

22、選取相應的參數(shù)a,b,c,d。給出了代碼行數(shù)與任務量、任務量與開發(fā)時間之間的函數(shù)關系 表3.6 簡單CoCoMo模型參數(shù)軟件類型 a b c d 適用范圍組織型 2.4 1.05 2.5 0.38 各類運用程序半獨立型 3.0 1.12 2.5 0.35 各類適用程序、 編譯程序等嵌入型 3.6 1.20 2.5 0.32 實時處置、 控制程序、 操作系統(tǒng) 2 中間CoCoMo模型中間CoCoMo模型 以根本CoCoMo模型為根底，在任務量估計公式中乘以任務量調理因子 EAF E = aLb *EAF (3-3)其中：L是軟件產(chǎn)品的目的代碼行數(shù) a,b是常數(shù)，取值如表3.7所示。中間 CoCo

23、Mo模型表3.7 中間CoCoMo模型參數(shù) 軟件類型 a b 組織型 3.2 1.05 半獨立型 3.0 1.12 嵌入型 2.8 1.20 CoCoMo模型 任務量調理因子EAF與軟件產(chǎn)品屬性、計算機屬性、人員屬性、工程屬性有關軟件產(chǎn)品屬性 軟件可靠性、軟件復雜性、數(shù)據(jù)庫的規(guī)模。計算機屬性 程序執(zhí)行時間、程序占用內(nèi)存的大小、軟件開發(fā)環(huán)境的變化、軟件開發(fā)環(huán)境的呼應速度。人員屬性 分析員的才干、程序員的才干、有關運用領域的閱歷、開發(fā)環(huán)境的閱歷、程序設計言語的閱歷工程屬性 軟件開發(fā)方法的才干，軟件工具的質量和數(shù)量、軟件開發(fā)的進度要求。 CoCoMo 模型四種屬性共15個要素。每個要素調理因子 Fi

24、, i=1,2,.,15,的值分為： 很低、低、正常、高、很高、極高，共六級。正常情況下 Fi=1。Boehm引薦的Fi值范圍 (0.70, 0.85, 1.00, 1.15, 1.30, 1.65) 當15個Fi的值選定后，EAF的計算如下 EAFF1*F2*F15 CoCoMo 模型 調理因子集的定義和調理因子定值是由統(tǒng)計結果和閱歷決議的。不同的軟件開發(fā)組織，在不同的歷史時期，隨著環(huán)境的變化，這些數(shù)據(jù)能夠改動。 運用中間CoCoMo模型可以估算開發(fā)軟件產(chǎn)品的任務量，比較各種開發(fā)方案的任務量。 例3.3 用根本CoCoMo模型估算例3.2任務量、開發(fā)時間和工程開發(fā)人數(shù)在例3.2中，目的代碼行

25、數(shù)為 33.3 KLOCCAD軟件開發(fā)屬于中等規(guī)模、半獨立型從表3.7中查到a=3.0，b=1.12。代入公式(3-1) E = 3.0L1.12 = 3.033.31.12 = 152 PM 將E的估算值代入公式 (3-2) 取 C=2.5 d=0.35 D=2.5E0.35 =2.5*1520.35 =14.5 M 建議參與工程開發(fā)的人數(shù) N=E/D=152/14.511例中計算出來的11人是粗略估計在軟件工程開發(fā)過程中，11個人不能夠都有一樣的才干和個性，一樣的閱歷和知識構造，并且在軟件開發(fā)的各個階段對人的要求也不同。 CoCoMo模型 假設干人共同開發(fā)一個軟件工程還應該添加他們之間相互

26、通訊和交換意見的額外任務量。 設 N個程序員組成小組，實現(xiàn)一樣規(guī)模的程序，相互通訊數(shù)為 =N(N-1)/2 每次通訊和交換意見的平均任務量為 那么 添加的通訊開銷為 EcN(N-1)/2 (3-4)例3.4 計算一個程序的通訊開銷 3人和5人開發(fā)一個程序相互通訊和交換意見的關系如下圖 將N=3和N=5分別代入公式(3-4) Ec(3)3(3-1)/23 Ec(5)5(5-1)/210 CoCoMo模型 由N個程序員組成的小組共同開發(fā)一個程序總的任務量ET滿足 ET=E+Ec (3-5)程序員小組的消費率是 PG=LOC/(E+Ec) (3-6)程序員小組消費率和單個程序員消費率的比為 Rp=E

27、/(E+Ec) (3-7) 隨著程序員小組人數(shù)的添加,EcN2/2，程序員小組的消費率將會下降。 模型闡明 盲目添加程序員人數(shù)會推遲軟件完成的日期 3.2.2.3閱歷估算模型之二：Putnam模型 1978年，Putnam提出了大型軟件工程任務量(普通在30人年以上)估算模型。它是一個動態(tài)多變量模型，適用于軟件開發(fā)的各個階段，估算模型以大型軟件工程的實測數(shù)據(jù)為根底，導出任務量分布曲線。該曲線與著名的Rayleigh-Norden (R-N)曲線類似，它描畫了開發(fā)任務量，開發(fā)時間和軟件代碼行數(shù)之間的關系。 Putnam模型方程 L = CK E1/3 td4/3 (3-8)其中：L 表示源程序代

28、碼行數(shù) td 表示開發(fā)時間 Ck 表示技術形狀常數(shù) E 表示任務量 (以人年記，包括維護)Putnam模型提示了軟件工程的任務量、軟件開發(fā)時間和程序代碼長度三者之間的關系Putnam模型差的軟件開發(fā)環(huán)境 軟件開發(fā)沒有方法學的支持，缺乏對文檔的評審，采用批處置方式。普通的軟件開發(fā)環(huán)境 應有軟件開發(fā)方法學的支持，有適宜的文檔和評審，采用交互處置方式。好的軟件開發(fā)環(huán)境 應采用CASE工具和集成化CASE環(huán)境。 CK= 2000 比較差的軟件開發(fā)環(huán)境 8000 普通的軟件開發(fā)環(huán)境 11000 比較好的軟件開發(fā)環(huán) Putnam模型 由(2-18) 3 3 4 E L / (CK*td ) (3-9)td

29、對應于Rayleigh-Norden曲線的最大值，表示軟件交付時任務量最大，參與軟件工程的人最多。當任務量估算出來之后，利用每人年的開銷($/PY)可以估算本錢。公式(3-9)闡明，開發(fā)軟件工程的任務量與交貨時間的4次方成反比，將0.9td替代(3-9)式的td計算E發(fā)現(xiàn)，提早10%的時間要添加52%的任務量，降低了軟件開發(fā)消費率。軟件開發(fā)過程中人員與時間的折衷是一個非常重要的問題。Putnam模型3.3.1風險分析風險的概念風險與將要發(fā)生的事情有關，研討風險就是研討明天將要發(fā)生的事情風險涉及思想、觀念、行為、地點、時間等多種要素風險隨條件的變化而改動，人們經(jīng)過改動、選擇、控制與風險親密相關的

30、條件減少、逃避風險改動、選擇、控制條件的戰(zhàn)略是不確定的3.3風險分析和管理軟件風險軟件風險和其它風險一樣存在不確定性,有些是很難預測的。對風險的不確定性進展量化，估算某一風險能夠帶來的損失。除關注軟件工程的普通性風險外，還要關注軟件工程的特殊風險，如工程的背景、特殊要求、關鍵內(nèi)容、薄弱環(huán)節(jié)、技術難點、人員情況、任務環(huán)境等。 軟件工程存在各種風險，人們關懷的問題：什么風險會導致軟件工程的徹底失敗?顧客需求、開發(fā)環(huán)境、目的機、時間、本錢的改動對軟件工程的風險會產(chǎn)生什么影響?人們必需抓住什么時機、采取什么措施才干有效地減少風險、順利完成義務? 不同類型的風險工程風險預算、進度、人力、資源、客戶及需求

31、工程的復雜度、規(guī)模、構造的不確定性等技術風險設計、實現(xiàn)、接口、驗證和維護規(guī)約的二義性、技術的不確定性、陳舊的技術、領先的技術商業(yè)風險無需求的產(chǎn)品、策路風險、管理風險、預算風險軟件風險分析包括的部分 風險標識 風險估算 風險規(guī)劃 風險監(jiān)控軟件風險分析1風險標識對待風險不能采取逃避態(tài)度 工程開場時應對普通性風險和特定產(chǎn)品風險進展系統(tǒng)標識，並隨著工程的展開不斷更新。普通可預測風險 產(chǎn)品規(guī)模、商業(yè)影響、客戶、過程、技術、環(huán)境、人員及閱歷等。識別風險的有效方法 風險檢測表 為了協(xié)助工程管理人員、工程規(guī)劃人員,全面了解軟件開發(fā)過程存在的風險， Boehm 建議設計并運用各類風險檢測表，表中條目指明,常見並

32、可預測的風險。有些風險可以預料，有些很難預料。例3.6 人員配備風險檢測表(1) 開發(fā)人員的程度如何。(2) 開發(fā)人員在技術上能否配套。(3) 開發(fā)人員的數(shù)量如何。(4) 開發(fā)人員能否可以自始至終地參與軟件開發(fā)任務。(5) 開發(fā)人員能否可以集中全部精神投入到軟件開發(fā)任務。(6) 開發(fā)人員對本人的任務能否有正確的期望。(7) 開發(fā)人員能否接受過必要的培訓。(8) 開發(fā)人員的流動能否可以保證任務的延續(xù)性。上述問題可以選用0,1,2,3,4,5來回答。完全一定取值為0，反之為5，中間情況分別取值1,2,3,4值越大表示風險越大。人員配備風險檢測表反映了人的要素給軟件工程帶來的風險。2風險估算 假設某

33、一風險檢測表由m項組成，每項選取一個整數(shù)值0,1,，N，在最理想的情況取值為0，反之取值為N，對于中間形狀依次取值1,2,N-1 當 N=1 時取值 0,1，對應布爾量真/假(T/F) 設第i種風險檢測表第j項取值Xij，對應的加權系數(shù)是Wij，于是第i種風險的估算值可以定義為 m i WijXij(mN) j=1 其中 Wij m， Wij 0 (310)風險估算 假設第i種風險對整個軟件工程的風險估算加權系數(shù)是i, i=1,2,l. 為風險要素的個數(shù),i1，那么軟件工程風險估算定義為 lRii (311) i=10R1當R接近于0時表示風險比較小，R接近于1時表示風險比較大。當ii 比較大

34、時，表示第i類風險出現(xiàn)并帶來不良影響的能夠性比較大，必需引起足夠注重，設法改善條件，減小i的值。3 風險評價和管理 風險評價是風險管理的重要步驟義務 進一步審查風險預測的精度；更新風險優(yōu)先次序；思索控制和/或防止能夠發(fā)生風險的方法。風險評價定義 用三元組ri， li， xi描畫風險，i =1,2,3 其中： ri 表示風險 li 表示風險發(fā)生的概率 xi 表示風險產(chǎn)生的影響 對大多數(shù)軟件工程，應該定義性能、本錢及進度的風險參考程度值，當某一風險或風險組合值超越程度值時工程被迫停頓。風險評價的步驟1 定義工程的風險參考程度值；2 建立三元組，給出相應的參考程度值；3 預測一組臨界點，定義工程終止

35、區(qū)域；4 預測什么樣的風險組合會影響參考程度 值風險表 13 風險 類別 概率 影響 RMMM123工程開場時應在第一列列出一切風險;第二列給出風險類別；第三列給出每種風險發(fā)生的概率；第四列給出各種風險產(chǎn)生影響的評價值；第五列給出風險緩解、監(jiān)控和管理方案。風險表23評價值按風險要素： 性能、本錢、進度的影響類別求加權平均值影響類別取值：災難的1，嚴重的2，細微的3，可忽略的4。對風險表中的風險按照發(fā)生概率大小、影響大小，由大至小排序。風險表33工程管理者對風險表進展研討后應定義一條中止線，線上的風險較大者應給予特別的關注，線下的風險需求進一步的跟蹤、評價、排序。對風險發(fā)生概率較大的事件應引起特

36、別關注，要及早采取措施盡量防止它的發(fā)生。風險評價和管理三元組ri,li,xi是風險管理的根底設 高級職員流動給工程帶來風險r1, 根據(jù)歷史的閱歷或直觀覺得，高級職員分開課題組的概率 l1 = 70%, 這一風險導致事件 x1 發(fā)生 工程開發(fā)時間延伸 15%，本錢添加 20%工程擔任人采取的風險管理措施(1)工程開場前控制產(chǎn)生風險的緣由。工程開工后應設法減輕風險的影響。(2)了解工程開發(fā)人員變動的緣由，在工程開發(fā)期間應控制上述緣由，盡量減少人員的流動。(3)在任務方法和技術上采取適當措施，防止因人員流動給任務帶來損失。(4)工程在開發(fā)過程中應及時公布并交流工程開發(fā)的信息。(5)建立組織機構，確定

37、文檔規(guī)范、并及時生成文檔。(6)對任務進展集體復審，使多數(shù)人都能了解任務的細節(jié)，跟上任務進度。(7)為關鍵技術預備后備人員。 RMMM方案風險緩解、監(jiān)控和管理方案 Risk Mitigation,Monitoring,and Management Plan 將風險分析任務文擋化，成為工程的一部分。執(zhí)行RMMM方案需求本錢 當軟件工程比較大時，能夠標出30至40種風險，假設為每種風險定義3至7種風險管理步驟，那么風險管理本身就是一個工程。將Pareto的20-80規(guī)那么用于軟件工程的風險標識，即20%的風險具有0.80的權，而其他的80%風險只需0.20的權。要擅長標識屬于20%的主要風險，降低

38、RMMM方案的規(guī)模和復雜性。RMMM方案大綱 方案大綱1.引言 1.1文擋的范回和目的 1.2主要風險綜述 1.3責任 1.3.1管理者 1.3.2技術人員2.工程風險表 2.1中止線以上的風險描畫 2.2影響概率及影響要素3.風險緩解、監(jiān)控和管理 3.1緩解 3.1.1普通戰(zhàn)略 3.1.2緩解風險的特定步驟 3.2監(jiān)控 3.2.1被監(jiān)控的要素 3.2.2監(jiān)控方法 3.3管理 3.3.1不測事件方案 3.3.2特殊思索4.RMMM方案時間安排表5.總結3.4 工程進度安排 制定軟件工程進度表有兩種途徑。 (1)軟件開發(fā)小組根據(jù)提供軟件產(chǎn)品的最后期限從后往前安排時間。 (2)軟件工程開發(fā)組織根據(jù)

39、工程和資源情況制定軟件工程開發(fā)的初步方案和交付軟件產(chǎn)品的日期。 軟件開發(fā)組織希望按照第二種方式安排任務進度。多數(shù)場所遇到的都是比較被動的第一種方式。 對軟件工程的進度安排比對軟件本錢的估算要求更高。本錢的添加可以經(jīng)過提高產(chǎn)品定價或經(jīng)過大批量銷售得到補償，而工程進度安排不當會引起顧客不滿，影響市場銷售。PERT技術和CPM方法PERT技術叫做方案評審技術程序評價與審查技術CPM方法叫做關鍵途徑法它們都是安排開發(fā)進度，制定軟件開發(fā)方案最常用的方法。它們都采用網(wǎng)絡圖來描畫一個工程的義務網(wǎng)絡，也就是從一個工程的開場到終了，把該當完成的義務用圖的方式表達出來。通常用兩張圖來表示。一張圖給出工程的一切義務

40、，另一張圖給出應按照什麼次序完成這些義務，給出各義務的銜接。PERT和CPM方法提供了定量描畫工具，包括關鍵途徑。完成關鍵途徑上一切義務時間的總和，就是工程開發(fā)所需求的最短時間。用統(tǒng)計模型估算開發(fā)每個子義務需求的任務量和時間。計算各子義務的最早啟動時間和最遲啟動時間。 例：某一工程進入編碼階段思索如何安排三個模塊A,B,C的開發(fā)任務，其中A是公用模塊，B和C的測試有賴于A的調試C為現(xiàn)成已有的模塊，但對它要做了解之后做部分修正。直到A,B,C做組裝測試為止。圖中各邊表示要完成的義務，數(shù)字表示完成該義務的繼續(xù)時間0為起點，8為終點。850412367起點A編碼B編碼A測試C修正C了解A調試BC組裝

41、測試C測試B測試B調試C調試68687886795終點開發(fā)模塊義務網(wǎng)絡圖BAQPPQNo.0N0.1N0.2在組織較為復雜的工程時或需求對特定的義務進一步做更為詳細的方案時,可以運用分層的義務網(wǎng)絡圖。分層義務網(wǎng)絡圖一個概念開發(fā)的義務網(wǎng)絡軟件工程的進度安排 1.義務分配、人力資源分配、時間分配要與工程進度相協(xié)調。 2.義務分解與并行化 3.任務量分布 4-2-4分布原那么 4.工程進度安排 運用程序評價與審查技術(PERT)或關鍵途徑方法(CPM) 生成義務網(wǎng)絡圖。軟件工程的進度安排進度安排的圖形方法甘特圖方案完成文檔編寫ABCDE1 2 3 4 5 6 7 8 9 10 11 12 13 14

42、 義務周當前進度完成評審時間表的例子 3.5 軟件質量度量1軟件質量度量及三層次度量模型2軟件質量要素3軟件質量要素評價準那么軟件質量度量及三層次度量模型軟件質量是軟件的生命，它直接影響軟件的運用與維護。質量低下的軟件不但影響基于計算機系統(tǒng)的任務效率，而且還能夠給用戶帶來災難性的后果。提高軟件產(chǎn)質量量是軟件工程的首要義務。軟件開發(fā)人員、管理人員、維護人員和用戶在軟件開發(fā)、維護、運用過程中所處位置不同，對軟件質量的了解和要求也不同。軟件質量度量1976年Boehm提出了定量評價軟件質量的概念，給出了60個軟件質量度量公式和軟件質量度量的層次模型1978年Walters和McCall提出了包括質量

43、要素(factor)、準那么(criteria)和度量(metric)的三層次軟件質量度量模型G.Murine又提出了軟件質量度量技術SQM用于定量地評價軟件質量1985年國際規(guī)范化組織(ISO)提出了軟件質量度量(SQM)任務報告 三層次軟件質量度量模型 質量要素 (factor)評價準那么 (criteria)度 量 (metric) 軟件質量要素軟件質量要素直接影響軟件開發(fā)過程各個階段的產(chǎn)質量量由于對軟件質量了解的不斷深化，軟件質量要素不是一成不變的McCall等人給出的軟件質量要素共11個，分為三類。 McCall的軟件質量要素軟件的運轉特征 正確性 可靠性 有效性 完好性 可用性軟件

44、接受修正的才干 可維護性 靈敏性 可測試性軟件對新環(huán)境的順應程度 可移植性 可重用性 可互操性 軟件的屬性正確性(Correctness)程序滿足規(guī)格闡明及完成用戶目的的程度。完好性(Integrity)控制未被授權人員訪問程序和數(shù)據(jù)的程度。可用性(Usability)學習運用軟件的難易程度。包括：操作軟件、為軟件預備輸入數(shù)據(jù)，解釋軟件輸出結果。靈敏性(Flexibility) 改動一個操作程序所需的任務量。可測試性(Testability) 測試程序使之具有預定功能所需的任務量?？苫ゲ傩?Interoperability) 兩個或多個系統(tǒng)交換信息并相互運用已交換信息的才干。 軟件質量要素之間的關系軟件質量要素之間有正相關，也有負相關。系統(tǒng)設計過程中應根據(jù)詳細情況對各種