第2章軟件項目管理中山大學計算機科學系衣楊目錄2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發過程的管理2.7軟件過程及軟件成熟度模型CMM2.8軟件項目管理的CASE工具

軟件項目管理概述項目管理過程啟動一個項目成本估算風險分析進度安排追蹤和控制目錄2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發過程的管理2.7軟件過程及軟件成熟度模型CMM2.8軟件項目管理的CASE工具2.1軟件度量度量（metrics）:對軟件產品、軟件開發過程或資源簡單屬性的定量描述，如：程序規模、操作符個數、程序中的錯誤的個數等。p29測量（measure）：度量的函數。用于事后或實時，涉及測量的方法、過程、工具和數值結果；p29估算（estimation）:度量的函數。是預測，用于簽定合同，立項、制定工作計劃。過程（process）:與軟件有關的活動，如：設計開發計劃、開發活動、管理活動等。軟件開發資源(resource):軟件開發過程中需要的各種支持，如人力、經費、軟硬件。2.1軟件度量軟件屬性：*外部屬性：體現了產品、過程、資源與環境的關系，如成本，效益，程序員的生產率，軟件產品的可靠性，可用性，可維護性…..,是面向管理者和用戶的屬性。內部屬性：軟件產品、過程和資源本身的屬性，如軟件產品的結構、模塊化程度，復雜性、程序長度。軟件外部屬性在軟件開發過程中很難測量和控制，通過研究軟件的內部屬性度量解決軟件外部屬性的度量問題，進而逐步建立軟件工程的度量體系。2.1軟件度量1.面向規模的度量用代碼行(LOC)數表示軟件項目的規模，利用它不僅可以測量軟件規模，還可以度量軟件開發的生產率，計算每行代碼的平均成本，計算文檔與代碼的比例管理，每千行代碼存在的軟件錯誤個數。2.1軟件度量1.面向規模的度量--生產率pl=L/EL:代碼行數，用千行代碼kLOC(1KLOC=103LOC)度量E:軟件項目的工作量，用人月(PM)度量。pl：軟件項目的生產率，用每人每月完成的代碼行數（LOC/PM）度量。2.1軟件度量1.面向規模的度量--每行代碼的成本Cl=S/LS:軟件項目的總開銷，用人民幣或美圓表示；Cl

：軟件項目每行代碼的平均成本，用人民幣元（美元）/代碼行度量2.1軟件度量1.面向規模的度量--文檔與代碼比Dl=Pd/LPd

：軟件項目的文檔頁數Dl：每千行代碼的平均文檔頁數2.1軟件度量1.面向規模的度量--代碼出錯率EQRl=Ne/L

Ne：軟件項目的代碼錯誤數

EQRl

：每千行代碼的平均錯誤數。2.1軟件度量1.面向規模的度量—優缺點用軟件代碼行估算軟件規模的優點：簡單易行。用軟件代碼行估算軟件規模的缺點：依賴于程序設計語言的表達能力；會對設計精巧的軟件項目產生不利的影響；在項目開發前或初期很難作到；適用于過程式的程序語言。2.1軟件度量2.面向功能的度量

Albrecht1979年提出,目前在歐共體很普遍，只涉及多種因素的間接度量方式。它根據事物信息處理程序的基本功能定義，因此在軟件系統涉及初期就能夠估算出軟件項目的規模。2.1軟件度量2.面向功能的度量--功能點FP用5個信息量的“加權和”CT和14個因素的“復雜性調節值”Fi

計算功能點FP。p322.1軟件度量

Fi=0noeffect

Fi={0,1,2,3,4,5}表示起作用的程度。

=5時最大。與用代碼行定義軟件項目的開發效率、成本等度量一樣，用功能點也可以定義相應的概念：2.面向功能的度量--生產率Pf=FP/EPf:每人每月完成的功能點數2.1軟件度量2.面向功能的度量--平均成本Cf=S/FPCl:每功能點的平均成本（REM,USD）2.1軟件度量2.面向功能的度量--文檔與功能點比Df=Pd/FPDf:每功能點平均具有的文檔頁數2.1軟件度量2.面向功能的度量--代碼出錯率EQRf=Ne/FP

EQRf:表示每個功能點的平均錯誤個數。2.1軟件度量2.面向功能的度量的應用分析軟件規模的功能點度量沒有直接設計軟件系統本身的算法復雜性，因此它適合算法比較簡單的事物系統的軟件規模度量。對比較復雜的軟件系統，如實時系統、大型嵌入式系統軟件、過程控制軟件不適用。2.1軟件度量面向功能度量的發展1986年Jones推廣了功能點的概念，把軟件項目中的算法復雜性因素因入到功能點中來。為了避免混淆，Albrecht定義的功能點稱為簡單功能點，用FPs

表示，Jones推廣的功能點稱為功能點，FP。推廣的功能點包括計算機程序中用于各類問題求解的算法因素，如求解線性代數方程組，求解遍歷二叉樹各結點，處理中斷，等等。對一般工程計算或事物處理軟件，用兩種方法計算出來的值應該基本相同，但對于復雜問題，FP>FPs

20%~35%.2.1軟件度量功能點度量的優缺點優點與程序設計語言無關，適用于過程式和非過程式語言。適用于軟件項目的開發初期。缺點涉及主觀因素較多信息領域某些值不易采集FP的值沒有直觀的物理意義。2.1軟件度量代碼行度量與功能點度量的比較代碼行依賴于程序設計語言，功能點不依賴程序設計語言。Albert和Jones統計出不同程序設計語言每個功能點與代碼行的關系，用LOC/FP表示.表明，Fortran/Ada=1.4,4GL/traditionallanguage=3~52.1軟件度量目錄2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發過程的管理2.7軟件過程及軟件成熟度模型CMM2.8軟件項目管理的CASE工具2.2軟件項目估算意義

軟件開發成本占總成本的比例很大，客戶和項目管理人員都十分重視軟件項目的成本估算。然而，軟件是邏輯產品，涉及人、技術、環境、政策等多因素，在項目完成之前很難估準確算出項目的開銷。參照已經完成的類似項目；將大項目分成若干小項目，再匯總；將軟件項目按生存周期分解，分別估算出軟件項目成本和在開發各個階段的工作量和成本，再匯總；根據實驗或歷史數據給出軟件項目工作量或成本的經驗估算公式。常用的四種估算方法：2.2軟件項目估算代碼行、功能點和工作量估算采用上述四種估算的方法可以估算出LOC或FP的樂觀值a,悲觀值b,一般值m。根據

e=(a+4m+b)/6得出期望值。希望LOC,FP落在[a,b]之外的概率極小。Ex:軟件項目規模FP=310;生產率pf

=5.5FP/PM,則工作量估算

E=310/5.5=56.2.2軟件項目估算經驗估算模型一：CoCoMo模型從以前的項目的實際數據導出，“從前的”，“局部的”，有一定的參考價值。1981年Boehm提出了“構造性成本模型”（ConstructiveCostModel,CoCoMo）.在靜態、單變量模型基礎上構造出來的。2.2軟件項目估算基本CoCoMo：用于系統開發的初期，估算整個系統的工作量（包括維護）和軟件開發所需要的時間；中間CoCoMo：用于估算各個子系統的工作量和開發時間；詳細CoCoMo：用于估算獨立的軟部件，如系統內部的各個模塊。2.2軟件項目估算基本CoCoMo模型(1)靜態、單變量模型，具有如下形式：E=a(KLOC)bD=cEdE:工作量，單位人月（PM）D:開發時間，單位是月KLOC：項目的代碼行估計值，單位是千行代碼a,b,c,d,是常數（齊治昌《軟件工程》P31fig2.9）2.2軟件項目估算基本CoCoMo模型(2)模型給出了代碼行數、工作量、工作量與開發時間之間的函數關系，Boehm將軟件劃分為組織型、半獨立型、和嵌入型三類，選取相應的a,b,c,d.2.2軟件項目估算中間CoCoMo模型以基本CoCoMo模型為基礎，在工作量估計公式中乘以工作量調節因子EAF。E=a(LOC)b

EAFLOC：項目的代碼行數a,b

：常數,見P38fig2.10工作量調節因子與軟件產品屬性、計算機屬性、人員屬性、項目屬性有關。2.2軟件項目估算軟件產品屬性：軟件可靠性、軟件復雜性、數據庫規模計算機屬性：程序執行時間、程序占用內存的大小、軟件開發環境的變化、軟件開發環境的響應速度。人員屬性：分析員的能力、程序員的能力、有關應用領域的經驗、開發環境的經驗、程序設計語言的經驗。項目屬性：軟件開發方法的能力，軟件工具的質量和數量、軟件開發的進度要求。中間CoCoMo模型

—同工作量調節因子相關的屬性(1)2.2軟件項目估算

上述屬性共15各要素，每個要素調節因子Fi

(I=1,2,~15):很低、低、正常、高、很高、極高六種，正常時Fi

＝1，Fi

=1,0.7~1.66,{0.70,0.85,1.00,1.15,1.30,1.65}.中間CoCoMo模型

—同工作量調節因子相關的屬性(2)2.2軟件項目估算中間CoCoMo模型

—同工作量調節因子相關的屬性(3)調節因子集的定義和調節因子定值是由統計結果和經驗決定的。不同的開發組織在不同歷史時期，隨著環境的變化，數據會變化。中間CoCoMo不僅可以估算開發軟件產品的工作量，還可以比較各種開發方案對工作連的影響。2.2軟件項目估算經驗估算模型二：Putnam模型1978，Putnam提出了大型軟件項目（>30persons）估算模型。該模型是動態、多變量的，適用于軟件開發的各個階段，以實測數據為基礎，導出p40fig2.3的工作量分布曲線。你從中可以看出什么信息？與著名的Rayleigh-Norden曲線形狀相似，描述了開發工作量、開發時間和軟件代碼行數之間的關系。2.2軟件項目估算Putnam模型－－方程式（1）L:源程序代碼行數；td:開發時間；Ck:技術狀態常數，（2000：比較差的軟件開發環境:沒有方法學的支持，缺乏對文檔的評審，用批處理方式；8000：一般的軟件開發環境:有方法學的支持，有適宜的文檔和評審，采用交互處理方式；11000比較好的軟件開發環境：采用CASE環境）。Putnam模型－－方程式（2）E:工作量2.2軟件項目估算

td:對應于R-N的最大值，表示軟件交付時的工作量最大，參與的人最多。當工作量估算出后，利用每人每年的開銷，估算成本。2.2軟件項目估算工作量與時間的關系工作量與時間不是線性關系，可以在不同階段改變人數。工作量與交貨時間4次方成反比，提前10%，增加52%的工作量，降低了軟件開發的生產率。2.2軟件項目估算

Putnam模型揭示了軟件項目的工作量、開發時間和程序代碼長度的關系，但沒有反映軟件產品屬性、軟件項目屬性、軟件開發人員的屬性、計算機硬件資源屬性，等。所以此模型是對軟件項目成本的粗糙估算。2.2軟件項目估算目錄2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發過程的管理2.7軟件過程及軟件成熟度模型CMM2.8軟件項目管理的CASE工具軟件質量概述－定義軟件質量（ANSI標準定義）是軟件產品或服務的特性和特征的整體，它取決于滿足給定需要的能力產品的價值取決于產品的質量，軟件質量的特性是多方面的。

2.3軟件質量度量軟件質量標準具備滿足給定需求的特性及特征的總體能力軟件擁有所期望的各種屬性組合程度用戶認為軟件滿足他們綜合期望的程度軟件組合特性可以滿足用戶期望需求的程度

2.3軟件質量度量軟件質量概述－－特征與明確確定的功能和性能需求的一致性。即軟件需求是質量度量的基礎，缺少與需求的一致性就無質量可言。與明確成文的開發標準的一致性。不遵循專門的開發標準，將導致軟件質量低劣。與所有專業開發的軟件所期望的隱含的特性的一致性。忽視軟件隱含的需求，軟件質量將不可信。

2.3軟件質量度量軟件質量概述－－軟件質量模型軟件質量的度量模型1976年，Boehm第一次提出了軟件質量度量的層次模型。1978年，Walters和McCall等人提出了從軟件質量要素、準則到度量的三個層次式的模型。p421985年，ISO建議軟件質量模型由三層組成：高層：軟件質量需求評價準則（SQRC）中層：軟件質量設計評價準則（SQDC）低層：軟件質量度量評價準則（SQMC）

2.3軟件質量度量McCall軟件質量模型McCall質量度量模型框架面向管理的產品質量決定產品質量的軟件屬性定量化度量軟件屬性使用單位自行制定SQDC可跟蹤性完備性一致性準確性容錯性簡單性模塊獨立性通用性可擴充性自檢(工具)性自描述性執行效率存儲效率存取控制存取審查操作性可訓練性通信性軟件系統獨立性機器獨立性通信共享性數據共用性簡明性SQRC正確性可靠性效率可維護性SQRC安全性可使用性靈活性互連性ISO軟件質量度量模型SQMC在軟件的眾多質量特性之間，質量特性與質量子特性之間存在著有利的影響和不利的影響。表12-3給出了軟件的各種質量特性之間的關系。包括有利和不利的影響關系。表12-4給出了軟件質量特性同質量子特性之間的關系。包括有利和不利的影響關系。軟件質量特性之間的競爭

2.3軟件質量度量A質量特性與質量子特性之間的關系p44質量特性之間有利和不利的影響目錄2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發過程的管理2.7軟件過程及軟件成熟度模型CMM2.8軟件項目管理的CASE工具McCabe復雜性度量法由McCabe于1976年提出Halstead的軟件科學由Halstead于1977年提出軟件質量的度量和評價－－兩種傳統的軟件復雜度度量方法2.4軟件復雜性度量程序的復雜性很大程度上取決于程序控制流的復雜性。單一的順序程序結構最簡單，循環和選擇所構成的環路越多，程序就越復雜。McCabe復雜性度量法TJ.McCabe，1976，提出了基于程序拓撲結構的軟件復雜性度量模型。2.4軟件復雜性度量1.畫出程序圖

McCabe度量法步驟（1）afbihegcd(a)程序流程圖abchgifed(b)程序圖2.4軟件復雜性度量McCabe度量法步驟（2）1.計算線性無關閉環數V(G)=e-n+1*其中e是結構圖中弧的條數，n是結構圖的節點數。abchgifed(b)程序圖V(G)=11-9+1=32.4軟件復雜性度量McCabe度量法的原理和結論

v(G)等于結構圖中有界或無界的封閉區域的個數。當程序中的分支結構數和循環結構數增加時，程序結構將復雜，v(G)增大。v(G)的值不要大于10，否則模塊內部結構就會變得復雜，給編碼帶來困難。在結構化程序中，力爭控制流從高層指向低層，反之，否則會增加封閉區域的個數。2.4軟件復雜性度量

Halstead復雜性度量法20世紀70年代初，M.Halstead從統計學和心理學的角度研究軟件復雜性問題。該方法的基本思路是根據程序中可執行代碼行的操作符和操作數的數目來計算程序的復雜性，一般來說，操作符和操作數的數目越大程序就越復雜。2.4軟件復雜性度量目錄2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發過程的管理2.7軟件過程及軟件成熟度模型CMM2.8軟件項目管理的CASE工具2.5軟件可靠性度量可靠性評估（Softwarereliabilityassessment，r（t））：根據軟件系統可靠性結構（單元與系統間可靠性關系）、壽命類型和各單元的可靠性試驗信息，利用概率統計方法，評估出系統的可靠性特征量。軟件的可靠性關系到整個系統的成敗軟件定義：系統連續運行某段時間的概率軟件修復排除軟件代碼中的錯誤。包括：發現錯誤、糾正錯誤、測試和系統重新啟動。可以降低程序故障率，提高軟件可靠性。2.5軟件可靠性度量不可修復系統：不允許停止程序運行的系統，如空管系統，反之為可修復系統。軟件修復時間：隨機變量，在可靠性分析中，使用平均修復時間的概念。2.5軟件可靠性度量

A（t）,系統在t時刻正常運行的概率。

A（250）=0.95.與R(250)=0,95.的區別。通常A（t）≥R（t）。對于不可修復系統，A（t）=R（t）系統有效性2.5軟件可靠性度量測量軟件有效性的方法（1）

（1）n臺相同的計算機硬件系統處理若干組相同或不同的輸入數據，如果發現故障，停機檢修，修復后重新啟動，t時刻如果有m(t)臺機器出現故障。M(0)=0.2.5軟件可靠性度量（2）系統在穩態運行過程中，仔細記錄一個程序運行的有效時間tuj和失效時間tdi，則程序在穩態運行的有效性：測量軟件有效性的方法（2）

（3）當系統處于穩態時，程序正常運行時間的平均值也是程序平均故障間隔tu時間(MTBF),程序平均停機時間td也是程序平均修復時間，于是系統穩態時的程序有效性：A=MTBF/(MTBF+MTTR)測量軟件有效性的方法（3）

第一種方法便于理解有效性的概念，但多數場合不能用；第二種方法可以度量已經投入運行的程序系統的有效性。第三種方法可以用在軟件開發階段。測量軟件有效性方法的使用目錄2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發過程的管理2.7軟件過程及軟件成熟度模型CMM2.8軟件項目管理的CASE工具2.6軟件開發過程的管理

--風險分析有風險、甚至是災難性的。涉及思想、概念、行為、地點、時間等諸多因素。什么風險可以導致項目的徹底失敗？顧客需求、環境、時間、成本會對項目產生什么影響？采取什么措施可以減少風險？

風險分析軟件工程中的風險分析包括：風險標識風險估算風險評價風險管理A)風險標識系統地確定對項目計劃（估算、進度、資源分配）的威脅通過識別一直的或可預測的風險，就能避開或駕馭風險。

風險分析風險的分類從宏觀上，風險分為項目風險：潛在的預選、進度、組織、資源、用戶和需求方面的問題，復雜性、規模的不確定性和結構的不確定性也構成項目的風險。技術風險：質量、交付期、設計、實現、接口、檢驗和維護；此外，規格說明書的多義性、技術的不確定性、技術陳舊。原因：問題的解決比預想的要復雜得多。商業風險：市場不需要、不符合公司的軟件產品戰略、銷售部門不知道如何推銷、失去上級部門的支持、預算風險。識別風險最好的方法是提出一組問題幫助項目計劃人員了解項目和技術方面有那些風險。Boehm“風險項目檢測表”肯定—0，反之—5，中間2，3，4。值大風險大。識別風險

風險分析B)風險估算從兩個方面估價每種風險：估計風險發生的可能性與風險相關的問題出現后會產生的結果。

風險分析項目計劃人員、管理人員、技術人員在一起，進行4種估計活動：建立一個尺度來表明風險發生的可能性；描述風險的后果估計風險對項目和產品的影響；指明風險估計的正確性以便消除誤解；風險評估活動c)風險評價使用三元組[Ri,li,xi]Ri是風險,li是風險出現的可能性,xi是風險的影響。一個對風險評價很有用的技術就是定義風險參照水準。對于大多數軟件項目來說，成本、進度和性能就是三種典型的風險參照標準。

風險分析D)風險管理為了執行風險駕馭和監控，必須考慮與每個風險相關的三員組[風險描述、風險發生概率、風險影響]，它們構成管理奉賢步驟的基礎。

風險分析2.6軟件開發過程的管理

--進度安排比成本估算更重要，可能造成市場的流失。軟件開發項目的進度安排有兩種考慮方式：系統交付期已經確定，軟件必須在規定期限內完成。經常遇到，如不能按時完成用戶會不滿意，甚至要求賠償經濟損失，所以必須在規定期限內合理分配人力和安排進度。系統交付期大致確定，開發部門自己確定軟件交付期。可以很好合理利用資源。任務分配、人力資源分配、時間分配要與工期進度協調：成立軟件開發小組，人數2~8。任務的分解和并行化.工作量分布：分析和設計40%~50%；編碼15%~20%；測試和調試30%~40%。工程進度安排：40-20-40規則可以作為一個指南fig2-13.2.6軟件開發過程的管理

--進度安排

軟件項目的人員組織大型軟件工程時間長，為了提高工作效率、保證質量，必須進行人員組織分工。軟件開發人員的個人素質與能力差異很大；軟件是智力產品，不易理解，不易維護；參加人員組織起來，發揮最大的工作效率。2.6軟件開發過程的管理

--進度安排按樹形結構組織軟件開發人員主程序員制民主制層次制主程序員制小組核心是一位主程序員、2~5位技術員，1位后援工程師組成。主程序員：小組全部技術活動的計劃、協調、審查工作，還負責設計和實現項目的關鍵部分；技術員：負責項目的具體設計和開發，文檔資料的編寫。后援工