ZLLBeiHua經理管什么？計劃預算組織進度標準什么是軟件項目管理？ZLLBeiHua第2章 軟件項目管理軟件項目管理必須從項目的開頭介入，并貫穿于整個軟件生存周期的全過程。軟件項目管理的范圍主要集中于3個P上，即：People（人員）、Problem（問題）和Process（過程）。軟件項目管理的主要任務是：根據選定的軟件開發過程框架（即軟件開發模型）和對其估算的結果制定軟件項目實施計劃；再根據計劃對人員進行組織、分工；按照計劃的進度，以及成本管理、風險管理、質量管理的要求，控制并管理軟件開發和維護的活動，最終以最小的代價完成軟件項目規定的全部任務。ZLLBeiHua第2章 軟件項目管理軟件項目的成本管理、軟件質量管理和軟件配置管理有一定的特殊性和獨立性，可單獨立項。任務分別是：成本管理估算軟件項目的成本，作為立項和簽合同的依據之一，并在軟件開發過程中按計劃管理經費的使用質量管理制定軟件質量保證計劃，按照質量評價體系控制軟件質量要素，對階段性的軟件產品進行評審，對最終軟件產品進行確認，確保軟件質量配置管理制定配置管理計劃，對程序、數據、文檔的各種版本進行管理，確保軟件的完整性和一致性ZLLBeiHua第2章 軟件項目管理2.1軟件度量

2.2軟件項目估算

2.3軟件質量度量

2.4軟件復雜性度量

2.5軟件開發過程的管理

ZLLBeiHua

軟件度量是軟件產品、軟件開發過程或自愿簡單屬性的定量描述。如程序規模、操作符個數、程序中錯誤的個數等。面向規模的度量面向功能的度量２.１.１軟件度量的基本概念ZLLBeiHua1）測量（measure）：對產品或過程的某個屬性的范圍、數量、維度、容量或大小提供一個定量的指示。2）度量（metric）：對系統、部件或過程的某一特性所具有的程度進行的量化測量。如軟件質量度量等。3）估算（estimation）：對軟件產品、過程、資源等使用歷史資料或經驗公式等進行預測。如工作量、成本、完成期限等。估算一般用于立項、簽訂合同、制定工作計劃等。4）指標（guideline）4）指標——是一個度量或度量的組合，它可對軟件產品、過程或資源提供更深入的理解。２.１軟件的度量ZLLBeiHua產品指軟件開發過程得到的文檔和程序，如：需求規格說明、設計規格說明、源代碼、測試報告等過程與軟件項目有關的活動，如軟件項目計劃、開發活動、維護活動、管理活動等資源進行軟件項目所需要的各種支持，如人力、經費、方法、工具、軟硬件環境等2．軟件項目管理的對象及其屬性——對象ZLLBeiHua內部屬性是指對象本身的屬性，如軟件產品的代碼長度、模塊化的程度、復雜性等。對象的外部屬性體現了對象與環境的關系，如軟件的可靠性、可維護性、可移植性、成本、人員的生產率等。對象的部分屬性如表2-1所示。2．軟件項目管理的對象及其屬性——對象的屬性ZLLBeiHua表2-1軟件工程的產品、過程、資源的屬性

產品過程資源內部屬性程序代碼行長度；程序功能；模塊化；控制流結構；重用性；模塊耦合度與內聚度。工作量；計劃及進度；事件。人員；方法；工具；環境；經驗。外部屬性軟件的可靠性；軟件的可理解性；軟件的有效性；軟件的可用性；軟件的可維護性；軟件的可移植性。成本；可控制性；可觀察性；穩定性。成本；生產率；時間。ZLLBeiHua直接度量對不依賴于其他屬性的簡單屬性的測量。如軟件的模塊數、程序的代碼行數、操作符的個數，工作量、成本等。度量分類間接度量即對涉及若干個其他屬性的軟件要素、準則或屬性的度量。如軟件的功能性、復雜性、可靠性、可維護性等等。.3．軟件度量的分類ZLLBeiHua圖2-1-1兩側面間關系面向規模的度量面向功能的度量面向人的度量生產率度量質量度量技術度量ZLLBeiHua2.1.2面向規模的度量

面向規模的度量是以軟件的代碼行（LOC，LineofCode）數為基礎的直接度量。

L表示軟件的代碼行數，單位為KLOC（千行代碼）或LOC；

E表示開發軟件所需工作量，單位為人月（PM）或人年（PY）；

S表示軟件成本，單位為美元或元；

N表示錯誤個數；

Pd表示軟件文檔頁數；

M表示開發所用的人數。ZLLBeiHua1．軟件開發的生產率P：P=L/E2．開發每行代碼的平均成本C：C=S/L3．代碼出錯率EQR：EQR=N/L4．軟件的文檔率D：D=Pd/L2.1.2

面向規模的度量ZLLBeiHua優點：簡單、直接。缺點：①代碼行數的估算依賴于程序設計語言的功能和表達能力。②對設計精巧的軟件項目產生不利影響。③在開發初期估算代碼行十分困難。④只適用于過程式程序設計語言。2.1.2

面向規模的度量ZLLBeiHua【例2.1】

已知有一個國外典型的軟件項目的記錄，開發人員M=6人，其代碼行數=20.2KLOC，工作量E=43PM，成本S=314000美元，錯誤數N=64，文檔頁數Pd=1050頁。試計算開發該軟件項目的生產率P、平均成本C、代碼出錯率EQR和文檔率D。解：根據給出的已知數據，可得：

P=L/E=20.2KLOC/43PM=0.47KLOC/PM=470LOC/PMC=S/L=314000美元/20.2KLOC=15.54美元/LOCEQR=N/L=64個/20.2KLOC=3.17個/KLOCD=Pd/L=1050頁/20.2KLOC=51.98頁/KLOCZLLBeiHua2.1.3面向功能的度量1．簡單功能點度量

1979年，Albrecht首先提出了功能點度量方法。這是一種面向功能的間接度量方法，即從軟件定義的基本功能出發，來估算軟件系統的規模。因此，該方法可以在軟件開發項目的初期，在軟件定義過程中即可預測待開發軟件的規模。ZLLBeiHua1．簡單功能點度量功能點FP的度量公式如下：FP=CT×TCF=CT[0.65+0.01∑Fi]

（2-5）其中：

CT——基本功能點。

CT值按表2-2來計算，它的值為5個參數加權值的總和。14i=1ZLLBeiHua表2-2簡單功能點度量的基本功能點的計算測量參數值加權因子加權值簡單一般復雜用戶輸入數×3×4×6=用戶輸出數×4×5×7=用戶查詢數×3×4×6=文件數×7×10×15=外部接口數×5×7×10=

基本功能點CTZLLBeiHua表2-2中的5個參數的含義1）用戶輸入數：用戶為軟件系統提供的輸入參數的個數（不包括查詢）；2）用戶輸出數：軟件為用戶提供的輸出參數（報告、屏幕幀、錯誤信息等）的個數；3）用戶查詢數：一次聯機輸入導致軟件以聯機輸出方式實時產生一個響應的個數；4）文件數：邏輯主文件的個數；5）外部接口數：機器可讀的接口（如磁盤或磁帶上的數據文件等）的個數。ZLLBeiHua1．簡單功能點度量在FP度量公式中：TCF——技術復雜性調節因子。0.65和0.01——經驗數據。Fi（i=1，2，…，14）——復雜性調節值。Fi所代表的因素如表2-3所示，每個Fi可根據實際情況取0、1、2、3、4、5中的一個值。其中：0—沒有影響、1—偶然的、2—適中、

3—普通、4—重要、5—極重要的影響。TCF取值范圍：0.65~1.35。ZLLBeiHua表2-3Fi

取值表i因素Fii因素Fi1234567需要可靠的備份和恢復嗎？需要數據通信嗎？有分布式處理的功能嗎？性能是關鍵嗎？在現存實用的操作環境下運行嗎？需要聯機數據入口嗎？聯機數據入口需要用輸入信息構造復雜的界面或操作嗎？891011121314

需要聯機更新主文件嗎？輸入、輸出、文件、查詢復雜嗎？內部處理過程復雜嗎？要求代碼設計可重用嗎？設計中包含轉換和安裝嗎？系統設計支持不同組織的多次安裝嗎？系統設計有利于用戶的修改、使用嗎？ZLLBeiHua2．功能點度量簡單功能點度量方法沒有直接考慮軟件本身的算法的復雜性問題。所以它僅適用于度量算法簡單的事務處理等系統。1986年Jones對簡單功能點度量進行了推廣，在計算軟件系統的基本功能點CT時，引入了算法復雜性因素，即使用表2-4計算CT。我們稱這種推廣的度量方法為功能點度量。這兩種方法對一般的事務處理系統等算法簡單的軟件系統計算出來的FP值基本相同，但對于較復雜的軟件系統，功能點度量方法比簡單功能點度量方法計算出來的FP值要高20%~35%。ZLLBeiHua表2-4推廣的功能點度量的基本功能點的計算測量參數值權值加權值用戶輸入數×4=用戶輸出數×5=用戶查詢數×4=文件數×7=外部接口數×7=復雜算法數×3=基本功能點CTZLLBeiHua用功能點計算軟件項目的有關參考量：1）生產率P（平均每人月開發的功能點數，以功能點/PM為單位）：

P=FP/E（2-6）2）平均成本C（以美元/功能點或元/功能點為單位）：

C=S/FP（2-7）ZLLBeiHua用功能點計算軟件項目的有關參考量：3）代碼出錯率EQR（即每功能點的平均錯誤數，以個/功能點為單位）為：

EQR=N/FP（2-8）

4）軟件的文檔率D（即平均每功能點的文檔頁數，以頁/功能點為單位）為：

D=Pd/FP

（2-9）ZLLBeiHua3．功能點度量方法的優缺點優點：①可用于軟件項目開發的初期階段的項目估算。因為在可行性研究和需求分析階段已能基本確定輸入、輸出等各個參考量；②與程序設計語言無關。適合于過程或非過程式語言。缺點：①某些參考量的收集有一定困難；②度量值的主觀因素較多，如Fi取值；③功能點FP本身沒有直觀的物理意義。ZLLBeiHua4．軟件的代碼行與功能點的關系軟件的功能點數和選用的程序設計語言無關，但對于同一個軟件（功能點數已定），如用不同的程序設計語言來實現，所得到的軟件的代碼行數可能會有較大差別。Albrecht等人通過多個軟件統計出了用不同程序設計語言實現每個功能點所需代碼行數，即計算出各語言的LOC/FP的平均值，如表2-5所示。ZLLBeiHua表2-5部分程序設計語言LOC/FP平均值的比較程序設計語言LOC/FP程序設計語言LOC/FP匯編語言C語言COBOLFORTRANPascal32012810510590Ada面向對象語言第四代語言（4GL）代碼生成器圖形語言（圖標）703020154ZLLBeiHua2.2軟件項目估算常用的軟件項目的估算方法主要有以下4種1．自頂向下的估算方法2．自底向上的估算方法3．差別估算法4．根據經驗估算公式2.2.1軟件項目的估算方法ZLLBeiHua基本思想：首先根據已完成項目的總成本或總工作量來推算待開發軟件的總成本或總工作量，然后再按比例將其分配到各開發任務中去。即從整體到局部。優點：估算工作量小、速度快。缺點：對項目中的特殊困難估計不足，有可能產生遺漏，估算出的值盲目性較大。1．自頂向下的估算方法ZLLBeiHua2．自底向上的估算方法基本思想是：把待開發軟件細分，直到每一個子任務或階段都已經明確所需要的開發工作量或成本，然后再把它們累加起來，得到待開發軟件的總工作量或總成本。優點：計算各個部分的準確性較高。缺點：缺少各個子任務之間相互聯系的工作量和系統工作量（如項目管理、配置管理、質量管理），估算值往往偏低，必須用其他方法進行校正。ZLLBeiHua3．差別估算法基本思想：把待開發的軟件項目與過去完成的軟件項目進行比較，從各子任務中區分出類似的和不同的部分。類似的部分按已知的實際量計算，不同的部分則采用某種方法進行估算。差別估算法綜合了以上兩種方法的優點。優點：估算的準確程度高。缺點：不容易劃分相似的界限。ZLLBeiHua4．根據經驗估算公式通過眾多實際軟件項目的經驗，總結出一些有價值的軟件成本和工作量估算的經驗模型。這些模型對于軟件項目管理具有一定的指導意義和驗證效果。ZLLBeiHua估算方法舉例【例2.2】Boehm給出了“軟件庫存情況更新”項目采用自頂向下估算方法的一個參考例子，由過去已完成的項目的工作量，估算出該項目的總工作量為53。然后將其按比例分配到各個階段，如表2-6所示。從中可以看出軟件開發各階段工作量的分配情況。ZLLBeiHua表2-6軟件項目的自頂向下估算

軟件庫存情況更新開發者：W.Ward日期：2/8/82階段任務工作量（1/53）小計（1/53）可行性研究與需求分析軟件需求定義56開發計劃1概要設計概要設計610初步用戶手冊3測試計劃1詳細設計詳細PDL描述412數據定義4測試數據及過程設計2正式的用戶手冊2編碼編碼616單元測試10組裝與聯合測試編寫文檔49組裝與聯合測試5總計53ZLLBeiHua2.2.2代碼行和功能點的估算采用2.2.1中介紹的估算方法可以估算出代碼行或功能點的樂觀值a、一般值m和悲觀值b，并用如下的加權平均公式計算LOC或FP的期望值（expectation）：

X=（a+4m+b）/6（2-10）軟件的LOC或FP的期望值估算出來后，就可以根據已有的標準生產率對成本和工作量等進行估算了。ZLLBeiHua【例2.3】對CAD軟件項目進行估算解：這里采用自底向上的估算方法。即首先，將CAD項目按功能分解為7個子項目，并估算出每個子項目LOC的樂觀值a、一般值m和悲觀值b，由此可估算出每個子項目的代碼行的期望值X。在根據已知的開發類似子項目的生產率P和平均成本C即可估算出每一個子項目的成本和工作量，最后將7個子項目的成本和工作量分別累加，即可估算出軟件項目的總成本S和總工作量E。估算的各種值如表2-7所示。ZLLBeiHua表2-7采用加權平均、自底向上方法估算代碼行、成本和工作量子項目a(LOC)m(LOC)b(LOC)X(LOC)每行成本C(美元/LOC)生產率P(LOC/PM)成本S(美元)

工作量(PM)用戶接口控制180024002700235014315329007.5二維幾何造型41005200750054002022010800024.5三維幾何造型48006900870068502022013700031.1數據庫管理2900350037003350182406030013.9圖形顯示40004900640050002220011000025.0外設控制2000210025002150281406020015.4設計分析66008500980084001830015120028.0總計33500659600145.4ZLLBeiHua估算的組織實施為了使估算更準確，可以組織幾個專家采用無記名的方式分別填寫表2-7，然后組織者計算出這幾個表格的平均值；這一過程可反復幾次，直到獲得一個得到多數專家共識的軟件規模。另外，還可以將每個子項目再按生存周期劃分，估算其各階段的工作量，再累加求出每個子項目的工作量和整個項目的工作量。可將用幾種方法估算的結果進行比較來驗證估算的準確性。ZLLBeiHua2.2.3軟件項目的經驗估算模型1．IBM模型——1977年，IBM公司對60個軟件項目的數據利用最小二乘法擬合，得到的經驗估算公式：

E=5.2×L0.91

（2-11）

D=4.1×L0.36=2.136×E0.3956

（2-12）

S=0.54×E0.6

（2-13）

DOC=49×L1.01

（2-14）其中：E為工作量（PM）；L為源代碼行數（KLOC）；

D為項目持續的時間，以月為單位；

S為人員需要量（人）；DOC為文檔數量（頁）。ZLLBeiHua2．Putnam模型1978年，Putnam提出了大型軟件項目的動態多變量估算模型。該模型以工作量在30人年以上的大型軟件項目的實測數據為依據，推導出了工作量分布曲線，如圖2-2-1所示。圖中的工作量分布曲線的形狀與著名的Rayleigh-Norden曲線相似。ZLLBeiHua圖2-2-1軟件項目的工作量分布曲線系統定義功能設計規格說明設計編碼測試和確認維護管理系統定義、需求分析開發運行維護0開發占總工作量的40%維護占總工作量的60%總工作量td時間t（年）工作量（人年）ZLLBeiHua2．Putnam模型Putnam估算模型如下：

L=CkE1/3td4/3Ck為技術狀態常數，與開發環境有關，如下：

2000較差，沒有方法學的支持，缺乏文檔和評審，采用批處理方式；Ck

=8000一般，有方法學的支持，有適當的文檔和評審，采用交互處理方式；

11000較好，有集成化的CASE工具和環境。E=L3/(Ck3td4)ZLLBeiHuaR-N分布線性分布01234t（年）td人年數\年圖2-2-2概率密度ZLLBeiHua圖2-2-2人力資源的分配初級技術人員高級技術人員管理人員驗收測試組裝測試單元測試編碼詳細設計概要設計需求分析系統定義人數ZLLBeiHuaPutnam模型的優缺點優點：揭示了軟件項目的源程序代碼長度、軟件開發時間和工作量三者之間的關系，在理論上有重要意義。缺點：準確程度不高。沒有反映軟件產品、項目、參加人員、軟硬件資源等屬性。ZLLBeiHua3．CoCoMo模型（構造性成本模型）CoCoMo模型按其詳細程度分三個層次：

基本CoCoMo模型；

中間CoCoMo模型；

詳細CoCoMo模型。2.2.3軟件項目的經驗估算模型ZLLBeiHua（1）基本CoCoMo模型其工作量和開發時間的估算公式如下：

E=aLb

D=cEd

其中：

L——

軟件代碼行的估算值（以KLOC計）；

E——

工作量（以PM計）；

D——開發時間（以月計）；

a、b、c、d——經驗常數。ZLLBeiHua表2-8a、b、c、d參數值的選取軟件類型abcd適應領域組織型2.41.052.50.38一般應用程序半獨立型3.01.122.50.35實用程序、編譯程序等嵌入型3.61.202.50.32實時控制程序、操作系統ZLLBeiHua（2）中間CoCoMo模型中間CoCoMo模型在估算工作量時，在基本CoCoMo模型的基礎上再乘以由15個因素組成的工作量調節因子EAF，于是有：

E=aLbEAF=aLb∏Fi

其中：

L——

軟件的代碼行數（以KLOC計）；

E——

工作量（以PM計）；

a、b——

經驗常數；i=115ZLLBeiHua表2-9a、b參數的取值軟件類型ab組織型3.21.05半獨立型3.01.12嵌入型2.81.20ZLLBeiHua（2）中間CoCoMo模型工作量調節因子EAF與軟件的產品的取值屬性、計算機屬性、人員屬性、項目屬性等因素有關。這15個因素Fi（i=1~15）的值可按等級取值，即可分為很低、低、正常、高、很高、極高，共6級。正常情況下Fi=1。Boehm推薦的Fi值的范圍是.70~1.66，F

i的值可根據實際情況按表2-10來選取。工作量E求出之后，就可以用公式（2-18）即D=cEd計算出開發時間D。ZLLBeiHua（3）詳細CoCoMo模型詳細CoCoMo模型的基本工作量（指EAF=1時的工作量）公式、開發時間公式與中間CoCoMo模型相同。所不同的是詳細CoCoMo模型在計算EAF時針對每個影響因素，分層次（系統層、子系統層、模塊層）并按軟件生存周期分階段給出工作量因素的分級表。詳細CoCoMo模型可以更準確地估算軟件項目的工作量。ZLLBeiHua表2-11子系統層軟件可靠性工作量因素分級表

階段可靠性級別需求分析和概要設計詳細設計編碼及單元測試集成及測試綜合很低0.800.800.800.600.75低0.900.900.900.800.88正常1.001.001.001.001.00高1.101.101.101.301.15很高1.301.301.301.701.40ZLLBeiHua通信工作量由N個程序員組成的程序員小組的通信數量：

C（N）=N（N-1）/2設：每兩個人之間通信的平均工作量為μ則：N人的程序員小組增加的通信工作量為：

EC=μC（N）=μN（N-1）/2（2-20）則該小組的總工作量ET為：

ET=E+EC

（2-21）ZLLBeiHua通信工作量如圖，由3人組成的程序員小組的通信數量：

C（3）=3（3-1）/2=3而由5人組成的程序員小組的通信數量：

C（5）=5（5-1）/2=10。當程序員小組的人數較多時，通信工作量EC≈μN2/2與人數的平方成正比，從而使程序員小組的生產率隨著人數的增加而迅速下降。由此可見，當在開發的后期發現不能按時交貨時，臨時盲目增加程序員將會更加推遲交貨的日期。ZLLBeiHua通信數圖2-2-4N=3和N=5時的通信數ZLLBeiHua4．COCOMOⅡ模型簡介COCOMOⅡ提供了3個層次的軟件開發工作量-進度估算模型，其估算的詳細程度逐步增加。①應用組裝模型該層次的模型可用于“應用組裝”類型的軟件項目的開發工作量-進度的估算；也可用于“應用程序生成器”、“系統集成”、“基礎結構”等類型的軟件項目的最早階段或螺旋周期的原型開發階段，以便解決像軟件/系統交互、用戶界面、性能和技術等的風險問題，該模型也適用于后期階段的原型開發。這類軟件項目或原型的開發可充分利用現成的構件。②早期設計模型該模型適用于“應用程序生成器”、“系統集成”、“基礎結構”等類型的軟件項目的早期設計階段，以便確定軟件或系統的體系結構或增量開發策略和操作概念、制定生命周期計劃等。③后體系結構模型早期設計階段結束，即已開發了軟件生命周期體系結構，確認了系統任務、風險、操作概念、生命周期計劃，建立了產品的框架后，即可采用該模型對軟件產品的實際開發與維護進行有效的估算。ZLLBeiHuaCOCOMOⅡ模型系列的估算公式①后體系結構模型公式

——軟件開發工作量代碼行的非線性函數：E=aLbFi

（2-22）b=c+0.01（2-23）在式2-22中，L為軟件的代碼行數；

E為工作量（以PM計）；

a為工作量系數；

b為工作量指數；工作量調節因子Fi（i=1～17）可分為很低、低、正常、高、很高、極高，共6級。正常情況下Fi=1。Fi的值可以根據實際情況按表2-12來選取。ZLLBeiHua工作量調節因子Fi的取值Fi屬性含義很低低正常高很高極高產品

屬性F1軟件可靠性（RELY）0.820.921.001.101.26F2數據庫規模（DATA）0.901.001.141.28F3軟件復雜性（CPLX）0.730.871.001.171.341.74F4可重用性（RUSE）0.951.001.071.151.24F5文檔級別（DOCU）0.810.911.001.111.23平臺

屬性F6執行時間約束（TIME）1.001.111.291.63F7內存約束（STOR）1.001.051.171.46F8平臺變更率（PVOL）0.871.001.151.30人員

屬性F9分析員的能力（ACAP）1.421.191.000.850.71F10程序員的能力（PCAP）1.341.151.000.880.76F11應用領域經驗（APEX）1.221.101.000.880.81F12平臺經驗（PLEX）1.191.091.000.910.85F13語言和工具經驗（LTEX）1.201.091.000.910.84F14人員連續性（PCON）1.291.121.000.900.81項目

屬性F15多地點開發（SITE）1.221.091.000.930.860.80F17軟件工具的使用（TOOL）1.171.091.000.900.78F17開發進度約束（SCED）1.431.141.001.001.00ZLLBeiHua后體系結構模型比例因子Wj的取值Wj比例因子含義很低低正常高很高極高W1項目先例性（PREC）6.204.963.722.481.240.00W2開發靈活性（FLEX）5.074.053.042.031.010.00W3體系結構與風險排除（RESL）7.075.654.242.831.410.00W4團隊凝聚力（TEAM）5.484.383.292.191.100.00W5過程成熟度（PMAT）7.806.244.683.121.560.00ZLLBeiHua②早期設計模型公式該模型也是把軟件開發工作量表示成代碼行的非線性函數：E=aLbFi

（2-24）b=c+0.01（2-25）式2-24與式2-22基本相同，所不同的是其工作量調節因子Fi（i=1～7）只有7個，是將后體系結構的17個調節因子分類組合而成。Fi的值可以根據實際情況按表2-14來選取。由表2-14可見，由于是多個調節因子組合成一個調節因子，因此，其等級分為極低、很低、低、正常、高、很高、極高，共7級。該階段估算的細致程度與所獲得的數據的細致程度相一致，與后體系結構模型相比較，是較粗粒度的估算。ZLLBeiHua早期設計工作量調節因子Fi的取值Fi調節因子含義極低很低低正常高很高極高對應后體系結構調節因子的組合F1產品可靠性與復雜性（RCPX）0.490.600.831.001.331.912.72RELY、DATA、CPLX、DOCUF2可復用性開發（RUSE）0.951.001.071.151.24RUSEF3平臺難度（PDIF）0.871.001.291.812.61TIME、STOR、PVOLF4人員能力（PERS）2.121.621.261.000.830.630.50ACAP、PCAP、PCONF5人員經驗（PREX）1.591.331.121.000.870.740.62APEX、PLEX、LTEXF6設施（FCIL）1.431.301.101.000.870.730.62TOOL、SITEF7要求的開發進度（SCED）1.431.141.001.001.00SCEDZLLBeiHua③COCOMOⅡ進度估算模型COCOMOⅡ提供了用于早期設計和后體系結構階段的簡單的進度估算公式。D=（d×E標稱f）× （2-26）f=（e+0.2×（b–c））（2-27）其中，D為開發時間（即進度），以月（Mo）為單位，以瀑布模型為例，指的是從確認一個產品的需求直到驗證產品已經滿足需求為止的整個開發時間；d為進度系數；E標稱為不考慮SCED工作量調節因子時所估算的工作量，稱為標稱工作量（以PM計）；g為要求的進度壓縮或擴展的百分數；f為進度指數；e為進度基本指數；b為工作量指數；c為工作量基本指數。ZLLBeiHua【例2.5】設有一個軟件開發項目的體系結構和需求已經確認，項目規模（包括新開發的代碼行和復用改編折算的代碼行）為100KLOC，試估算該項目當要求進度壓縮為標稱進度的75%（即g=75）時的開發時間和開發成本。假設估算時所有的工作量調節因子Fi和比例因子Wj都取正常值、承擔該項目的開發組織的平均工資為W=6000元/PM。解：由于該項目的體系結構已經確立，所以應采用COCOMOⅡ的后體系結構模型來估算工作量：b=c+0.01=0.91+0.01×（3.72+3.04+4.24+3.29+4.68）≈1.01E標稱=aLbFi=2.94×1001.01×1.00≈308PM該項目的進度（即開發時間，單位以月（Mo）計）為：f=e+0.2×（b–c）=0.28+0.2×（1.01–0.91）=0.3D=（d×E標稱f）×=3.67×3080.3×75/100≈15.4Mo進度壓縮后的實際估算工作量為：E=aLbFi=2.94×1001.01×1.00×1.43≈440PM軟件開發成本為：S=E×W=440×6000=2640000元ZLLBeiHua成功的標準：2.3軟件質量度量失敗的根本原因：

用戶在用用戶可很容易做完要做的事開發人員寫出的東西達不到用戶要求(人的問題、技術問題)ZLLBeiHua2.3軟件質量度量軟件質量是軟件的生命。它作為軟件工程的一部分，貫穿于整個軟件生存周期之中。生產高質量的軟件產品是軟件工程的首要目標。由于軟件是邏輯產品，軟件質量很難直接度量。因此，應當給出軟件質量的科學的、實用的定義，并通過一定的度量模型進行度量，以便在整個軟件生存周期中對其進行評價和控制。ZLLBeiHua2.3.1軟件質量的定義1983年，ANSI/IEEEstd729標準給出了軟件質量的定義如下：軟件質量是軟件產品滿足規定的和隱含的與需求能力有關的全部特征和特性，包括：

1．軟件產品滿足用戶要求的程度；

2．軟件擁有所期望的各種屬性的組合程度；

3．用戶對軟件產品的綜合反映程度；

4．軟件在使用過程中滿足用戶需求的程度。ZLLBeiHua2.3.2軟件質量的度量模型軟件質量與軟件的內部特性及其組合有關。要度量軟件質量，就應根據這些內部特性（即軟件屬性）建立起軟件度量模型，進而構建軟件質量度量體系。1976年，Boehm提出了定量度量軟件質量的概念，他給出了軟件質量的層次模型，并給出了60個軟件質量度量公式；1978年，Walters和McCall提出了三層次軟件質量度量模型；1985年，ISO提出了SQM（SoftwareQualityMetric，軟件質量度量）工作報告等等。ZLLBeiHua1．McCall等人的軟件質量度量模型McCall等人提出了由軟件質量要素、評價準則、定量度量三個層次組成的三層次度量模型。其中:第一層是將對軟件質量的度量歸結為對直接影響軟件質量的若干個軟件質量要素的度量；第二層是用若干個可度量的評價準則來間接度量軟件質量要素；第三層是對相應評價準則的直接度量。ZLLBeiHua圖2-3-1軟件質量三層次度量模型要素j評價準則1評價準則2評價準則L度量1度量2度量L……ZLLBeiHua2．軟件質量要素軟件質量要素（factor）是指直接影響軟件質量的軟件質量特性。隨著對軟件質量的認識的逐步提高，軟件質量要素也可能有所變化。當時McCall等人認為，軟件質量由11個軟件質量要素來衡量。這11個質量要素可劃分為三類：面向運行特征的軟件質量要素有正確性、可靠性、有效性、完整性和可用性；面向軟件承受修改的質量要素有可維護性、靈活性、可測試性；面向轉移的軟件質量要素有可移植性、可重用性、可互操作性。這三類要素構成了軟件質量的三個側面，如圖2-3-2所示。ZLLBeiHua圖2-3-2軟件質量要素的構成產品修正產品轉移產品運行

可維護性靈活性可測試性可移植性可重用性可互操作性正確性可靠性有效性完整性可用性ZLLBeiHua質量要素新概念正確性1程序滿足需求規格說明及用戶目標的程度2指對未授權人員訪問程序或數據加以控制的程度；完整性3

指學習使用軟件（即操作軟件、準備輸入數據、解釋輸出結果等）的難易程度可用性ZLLBeiHua質量要素新概念靈活性4指改變一個操作的順序所需工作量的多少5指測試軟件以便使其具有預定功能所需工作量的多少可測試性6指程序與其他系統相互交換并使用信息的能力可互操作性ZLLBeiHua2．軟件質量要素軟件質量要素不是獨立的，一個要素可能與其他幾個要素有關系，如表2-12所示，其中:

正相關以“√”表示，負相關以“×”表示。對于具有負相關的質量要素，在開發時應根據具體情況加以取舍或進行折衷。例如，對于實時控制系統，必須確保系統的可靠性和有效性，而軟件的可重用性、可移植性等質量要素就可以放寬要求。ZLLBeiHua

質量要素間的關系

關系要素要素正確性可靠性有效性完整性可用性可維護性靈活性可測試性可移植性可重用性可互操作性正確性

可靠性√有效性完整性×

可用性√√×

√可維護性√√×

√靈活性√√×

×

√√可測試性√√×

√√√可移植性×

√√可重用性×

×

×

√√√√可互操作性×

×

√ZLLBeiHua3．軟件質量要素的評價準則軟件質量要素一般很難直接測量。為了對11個要素進行度量，McCall等人通過確定影響軟件質量要素的屬性，定義了21個軟件質量要素的評價準則。這些評價準則既能夠比較完整、準確地描述軟件質量要素，又比較容易測量。通過這組評價準則就可以間接測量軟件質量要素，進而度量整個軟件質量。ZLLBeiHua評價準則新概念1）可審查性（audit-ability）：檢查軟件需求、文檔、過程、標準等是否一致的難易程度；2）準確性（accuracy）：計算和控制的精確程度；3）簡明性（conciseness）：程序源代碼的緊湊程度；4）通信通用性（communicationcommonality）：使用標準接口、協議和帶寬的程度；5）數據通用性（datacommonality）：在程序中使用標準數據結構和類型的程度；6）容錯性（error-tolerance）：在各種異常情況下軟件能繼續提供操作的能力；ZLLBeiHua評價準則新概念7）執行效率（executionefficiency）：軟件運行效率；8）可擴充性（expandability）：結構、數據、過程等設計可以擴充的程度；9）通用性（generality）：程序潛在應用領域的多少；10）硬件獨立性（hardwareindependence）：軟件與其運行的硬件環境無關的程度；11）檢測性（instrumentation）：程序監視自身運行并標識錯誤的程度；12）可操作性（operability）：操作該軟件的難易程度；ZLLBeiHua評價準則新概念13）安全性（security）：控制或保護程序和數據不被破壞、非法訪問等機制的能力；14）自文檔化（self-documentation）：源代碼提供自身說明文檔的程度；15）簡單性（simplicity）：程序易于理解的程度；16）軟件獨立性（softwareindependence）：軟件與非標準編程語言特征、操作系統特征等軟件環境約束無關的程度；17）易培訓性（training）：軟件對使用它的新用戶的支持程度。ZLLBeiHua質量要素與評價準則的關系

評價準則關系質量要素可追蹤性完全性一致性容錯性準確性簡單性可操作性執行效率可審查性檢測性安全性數據通用性可擴充性通用性硬件獨立性簡明性通信通用性自文檔化軟件獨立性易培訓性模塊化正確性√√√可靠性√√√√有效性√√√完整性√√√可用性√√可維護性√√√√√√靈活性√√√√√√√可測試性√√√√√可移植性√√√√√可重用性√√√√√可互操作性√√√√ZLLBeiHua4．軟件質量要素的度量第j種軟件質量要素Fj（j=1,2,…,11）的計算公式為：

Fj=∑CjkMk

（2-21）其中：Mk是第j種軟件質量要素Fj對第k種評價準則的測量值。評價準則多數只能按主觀想法定值。McCall將每個評價準則都劃分為0~10級，并且Mk的值可以在0，0.1，0.2，…，1.0中取一個。加權系數Cjk滿足∑Cjk=1，Cjk≥0。

Cjk=0表示質量要素與第k種評價準則無關。ZLLBeiHua4．軟件質量要素的度量例如，要度量某軟件的F2（可靠性）假設C23=0.1，C24=0.3，C25=0.4，C26=0.2，其余的C2k=0，而M3=0.7、M4=0.6、M5=0.5，M6=0.8，則可靠性的度量值為：

F2=C23M3+C24M4+C25M5+C26M6=0.1×0.7+0.3×0.6+0.4×0.5+0.2×0.8=0.61ZLLBeiHuaISO三層次軟件質量度量模型。1985年，國際標準化組織也提出了三層次軟件質量度量模型。其中：高層稱為軟件質量需求評價準則（SQRC），并由正確性、可容性、有效性、安全性、可用性、可維護性、靈活性、可互操作性等8個要素組成；中層稱為軟件質量設計評價準則（SQDC），并由可追蹤性、完全性…、等共23個評價準則組成；低層稱作軟件質量度量評價準則（SQMC）。ISO認為，應對高層和中層建立國際標準，而低層可由各使用單位自行制定。ZLLBeiHua2.4軟件復雜性度量通過軟件的復雜性度量值可以估算出軟件中故障的數量；也能估算出軟件開發所需的工作量；定量度量的結果還可以用于比較不同設計方案的優劣。同時，軟件的復雜性也能從某些方面影響軟件的可維護性、可靠性等軟件質量要素。

因此，軟件復雜性度量是軟件度量的一個重要組成部分。ZLLBeiHua2.4.1軟件復雜性的概念及度量原則

1．軟件復雜性的概念K.Magel從6個方面來描述軟件復雜性：

1）理解程序的難度；

2）維護程序的難度；

3）向其他人解釋程序的難度；

4）按指定方法修改程序的難度；

5）根據設計文件編寫程序的工作量；

6）執行程序時需要資源的多少。軟件復雜性反映了軟件的可理解性、模塊化、簡單性等屬性。ZLLBeiHua2．軟件復雜性度量的原則軟件復雜性的度量，的一些基本原則：

1）軟件的復雜性與其規模的關系不是線性的；

2）數據結構復雜的程序較復雜；

3）控制結構復雜的程序較復雜；

4）轉向語句使用不當的程序較復雜；

5）循環結構比選擇結構復雜、選擇結構比順序結構復雜；

6）語句、數據、子程序模塊等出現的順序對復雜性有影響；ZLLBeiHua2．軟件復雜性度量的原則7）非局部變量較多的程序較復雜；8）參數按地址調用（Callbyreference）比按值調用（Callbyvalue）復雜；9）函數副作用比顯式參數傳遞難理解；10）作用不同的變量同名時較難理解；11）模塊、過程間聯系密切的程序較復雜；12）程序嵌套層數越多越復雜。以上這些基本原則是指導我們進一步研究定量度量軟件復雜性的基礎。ZLLBeiHua2.4.2McCabe度量模型McCabe給出了程序控制結構圖G的巡回秩數V（G）作為程序控制結構復雜性的度量，其度量模型為：

V（G）=E–N+2（2-22）其中：E——程序圖G中邊的總數；

N——程序圖中結點的總數。

V（G）又稱為圖G的環形復雜度。可以證明，V（G）的值等于結構圖中有界和無界的封閉區域的個數。ZLLBeiHuaR1

三種基本結構的程序圖R1R2R1R2（a）順序結構V（G）=E–N+2=1–2+2=1

（b）選擇結構V（G）=E–N+2=4–4+2=2（c）while結構R1R2V（G）=E–N+2=3–3+2=2（d）until結構V（G）=E–N+2=3–3+2=2ZLLBeiHua2.4.2McCabe度量模型程序結構的復雜性度量值V（G）取決于程序控制流的復雜程度。當程序內的分支數和循環數增加時，V（G）值將隨之增加，即程序的復雜性增大。McCabe研究大量程序后指出，V（G）可作為程序規模的定量指標，V（G）值越高的程序往往是越復雜、越容易出問題的程序。McCabe建議模塊規模應滿足：V（G）≤10ZLLBeiHua【例2.6】程序流程圖如圖2-4-2所示，試求出其巡回秩數V（G）解：（1）畫出程序流程圖對應的程序圖。開始abchgfdei結束圖2-4-3程序圖abcfghdeiR1R2R3R41234567891011圖2-4-2程序流程圖ZLLBeiHua（2）由程序圖（或流圖）可得：abcfghdeiR1R2R3R41234567891011（3）由程序圖可以看出，其有界區域有R1、R2、R3共3個，還有1個無界區域R4，共4個封閉區域，所以：V（G）=E–N+2=11–9+2=4

V（G）=4【例2.5】程序流程圖如圖2-4-2所示，試求出其巡回秩數V（G）ZLLBeiHua2.4.3Halstead度量模型20世紀70年代初，Halstead給出了稱為文本復雜性度量的模型。它是根據統計程序中的操作符和操作數的個數來度量程序的復雜程度。程序可以看成是由操作符和操作數組成的符號序列。操作符是指程序中出現的語法符號，如+、–、if-then-else、while等。操作數是操作對象，如程序中定義或使用的變量、常量、數組、指針等。令：N1為程序中操作符出現的總個數，

N2為程序中操作數出現的總個數。則程序的語言符號長度N定義為：N=N1+N2。ZLLBeiHua2.4.3Halstead度量模型如果已經測得程序中不同操作符的個數n1和不同操作數的個數n2，則程序的長度N可用下式來估算：

N≈n1log2n1+n2log2n2

（2-23）Halstead用下式來定義程序量（即程序在詞匯上的復雜性）：

V=Nlog2（n1+n2

）（2-24）Halstead還給出了預測錯誤數的公式如下：

E=Nlog2（n1+n2

）/3000（2-25）ZLLBeiHua2.4.3Halstead度量模型可以對多個某種程序設計語言的程序進行統計分析，從而得出每千代碼行（KLOC）或每個功能點（FP）所包含的操作符和操作數個數CL或CF，于是，可以將程序語言符號長度N折合成相應的代碼行數或功能點數。ZLLBeiHua2.5軟件開發過程的管理在前幾節中介紹了軟件度量和估算，這些即是評價軟件的重要依據，也是軟件開發過程管理的組成部分和基礎。在本節中將介紹軟件項目管理的過程、風險分析，軟件開發計劃的進度安排，軟件開發人員的組織與分工等等。2.5.1軟件開發項目管理過程為達到軟件工程的目標，必須對軟件開發項目的工作范圍、所需的工作量和成本、必需的人力和軟硬件資源、可能遇到風險、進度的安排、待實現的任務、經歷的里程碑等進行管理。軟件開發過程的管理應在所有技術工作開始之前啟動，直至軟件工程過程的結束。ZLLBeiHua軟件開發項目管理過程主要包括以下幾個方面：1．啟動一個軟件項目

2．成本估算3．風險分析4．進度安排5．追蹤和控制ZLLBeiHua風險分析風險的特點：①不確定性，某項風險可能發生也可能不發生；②損失，一旦某項風險變成了現實，就必然會給項目帶來不良的影響和損失，甚至災難性后果。（1）按照風險的影響范圍分類

①項目風險

②技術風險

③商業風險2.風險分類：

（2）按照風險的可預測性分類

①已知風險

②可預測的風險

③不可預測的風險ZLLBeiHua風險分析3.風險分析的三個主要活動：

風險標識；風險估算；處理風險的策略。Ifyoudon’tactivelyattacktherisks,theywillactivelyattackyou.——TomGilb(1988)ZLLBeiHua

人員風險檢測表序號問題回答（0、1、2、3、4、5}1開發人員的水平如何？22開發人員在技術上是否配套？13是否有足夠的人員可用？04開發人員是否能自始至終參加軟件項目的工作？25開發人員是否能把全部精力投入到軟件開發工作中？26開發人員對自己的工作是否有正確的期望？17開發人員是否已接受了必要的培訓？08開發人員的流動是否還能保證工作的連續性？3ZLLBeiHua2．風險估算——風險預測。軟件項目管理人員主要從影響風險的因素和風險發生后帶來的損失來度量風險。要對風險進行估算，首先應建立風險度量指標體系、指明風險帶來的影響和損失，確定影響風險的因素，估計風險出現的可能性或概率，即進行定量的估算。估算方法如下：設：某一風險檢測表由m項組成，每項可在0，1，2，…，N中根據實際情況選取一個整數值。其中0表示最好情況，N表示最差情況。又設：第i種風險檢測表的第j項取值為Xij，對應的加權系數為Wij，則第i種風險的估算值可以定義為：

σi=∑WijXij/（mN）（2-47）

mj=1ZLLBeiHua2．風險估算其中：∑

Wij=m，Wij≥0

設：第i種風險對整個項目的風險估算的加權系數為ρi，i=1，2，…，l，其中l為風險的種類數，且滿足ρ1+ρ2+…+ρl=1，則整個軟件項目的風險估算值R定義為：R=∑ρiσi=∑ρi[∑WijXij/（mN）]（2-48）容易驗證，0≤R≤1。估算的結果，如果R接近于0，說明項目風險比較小，如果R接近于1，說明項目風險比較大。如果ρiσi的值比較大，說明第i類風險出現的可能性比較大。mj=1mj=1

li=1

li=1ZLLBeiHua3．風險評價常采用三元組[ri，pi，xi]來描述風險。其中ri代表第i種風險，pi表示第i種風險發生的概率，xi代表該風險帶來的影響，i=1，2，…，l，表示軟件開發項目共有l種風險，i為風險序號。一個風險評價技術就是定義風險參照水準。對于大多數軟件項目來說，成本、進度、性能就是典型的風險參照水準。在軟件開發過程中由于成本超支、進度拖延、軟件性能下降、支持困難，或它們的某種組合，都有一個水準。當軟件項目的風險的某種組合達到或超過了一個或多個參照水準時，項目就應終止。ZLLBeiHua3．風險評價比如，在軟件開發的過程中，項目的進度應與投入的成本相一致，如果投入的成本與進度的拖延之間超過某一個參照水準時，項目就應該終止。圖2-6-1給出了這樣的參照曲線，當風險的一個組合所引起的成本超支和進度拖延超過參照水準而進入圖中的封閉區域時，項目將被迫終止。ZLLBeiHua3．風險評價2-6-1風險參照水準參照點（成本，時間）將造成項目終止。估算成本超出估計進度超出ZLLBeiHua3．風險評價一般來說，參照點不是一條平滑的曲線，而是一個易變動的區域，在這個區域要做出基于參照值組合的管理判斷往往是不準確的。因此，風險評價過程可分四步進行：

1）定義項目的風險參照水準；

2）定義每種風險的三元組[ri，pi，xi]，并找出和每個參照水準之間的關系；

3）預測一組參照點以定義一個項目終止區域，用一條曲線或一些易變動區域來定界；

4）預測各種風險組合的影響是否超出參照水準。ZLLBeiHua4．風險駕馭和監控風險分析的目的是建立處理風險的策略，監控、駕馭風險。駕馭風險是利用原型化、軟件自動化、可靠性工程學等技術和軟件項目管理方法設法避開或轉移風險。描述風險的三元組[ri，pi，xi]是駕馭風險的基礎。風險駕馭與監控活動如圖2-6-2所示。ZLLBeiHua4．風險駕馭和監控圖2-6-2風險駕馭和監控風險駕馭風險1風險2風險n風險1分析數據[r1，p1，x1]風險1駕馭步驟風險2分析數據[r2，p2，x2]風險2駕馭步驟風險n分析數據[rn，pn，xn]風險n駕馭步驟風險駕馭和監控計劃…ZLLBeiHua【例】對開發人員的頻繁流動這一風險的駕馭與監控設:人員的流動給項目帶來的風險為r1，該風險發生的概率的估算值p1為70%，而該風險的出現給項目帶來的影響的估算值x1是項目開發時間延長15%，總成本增加20%。軟件項目管理人員可以采取以下的風險駕馭步驟：1）項目開始前要控制人員流動的原因，項目開始后要設法減輕風險的影響；2）了解開發人員變動的原因，在開發期間對這些原因加以控制，降低風險發生的概率；ZLLBeiHua3）采用適當的方法和技術以防止人員流動給項目帶損失；4）建立項目組，在開發的過程中應及時公布、交流項目開發信息；5）制定文檔標準，建立及時生成文檔的機制；6）對工作組織集體評審，使多數人都能了解工作的細節和按計劃進度完成自己的工作；7）為關鍵技術培養后備人員。一個大型軟件項目的開發可能存在30～40種風險。如果每一種風險都有3～7個風險駕馭步驟，則風險駕馭和監控本身也可能構成一個子項目，所以它也需要人力、時間和經費。ZLLBeiHua4．風險駕馭和監控為了更好地對風險進行駕馭和監控，應制定詳細的風險駕馭與監控計劃（RMMP，RiskManagementandMonitoringPlan），RMMP中給出了風險分析的全部工作。風險駕馭與監控計劃隨著軟件項目的開始而開始。風險駕馭與監控的主要目標有三個：1）判斷一個預測的風險是否已經發生；2）確保針對每一個風險而制定的風險駕馭步驟正在合理地實施；3）收集有關風