第13章軟件項目管理13.1估算軟件規模13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.6軟件配置管理13.7能力成熟度模型13.8小結習題本章要求掌握估算軟件規模的方法掌握COCOMO模型等工作量估算方法掌握進度計劃的方法掌握Gantt圖和工程網絡圖的特點和畫法。掌握項目人員的組成掌握軟件質量保證的措施掌握軟件配置管理的過程熟悉能力成熟度模型13.1估算軟件規模代碼行技術依據以往開發類似產品的經驗和歷史數據，估計實現一個功能所需要的源程序行數。把實現每個功能所需要的源程序行數累加起來，就可得到實現整個軟件所需要的源程序行數。13.1.1代碼行技術每個人都估計程序的最小規模(a)、最大規模(b)和最可能的規模(m)，分別算出這3種規模的平均值,和之后，再用下式計算程序規模的估計值： L= (13.1)用代碼行技術估算軟件規模時，當程序較小時常用的單位是代碼行數（LOC），當程序較大時常用的單位是千行代碼數（KLOC）。代碼行技術的主要優點是，代碼是所有軟件開發項目都有的“產品”，而且很容易計算代碼行數。代碼行技術的缺點是：源程序僅是軟件配置的一個成分，用它的規模代表整個軟件的規模似乎不太合理；用不同語言實現同一個軟件所需要的代碼行數并不相同；這種方法不適用于非過程語言。為了克服代碼行技術的缺點，人們又提出了功能點技術。13.1.2功能點技術功能點技術依據對軟件信息域特性和軟件復雜性的評估結果，估算軟件規模。這種方法用功能點（FP）為單位度量軟件規模。1.信息域特性功能點技術定義了信息域的5個特性，分別是輸入項數(Inp)、輸出項數(Out)、查詢數(Inq)、主文件數(Maf)和外部接口數(Inf)。（1）輸入項數：用戶向軟件輸入的項數，這些輸入給軟件提供面向應用的數據。輸入不同于查詢，后者單獨計數，不計入輸入項數中。（2）輸出項數：軟件向用戶輸出的項數，它們向用戶提供面向應用的信息，例如，報表和出錯信息等。報表內的數據項不單獨計數。（3）查詢數:

查詢即是一次聯機輸入，它導致軟件以聯機輸出方式產生某種即時響應。（4）主文件數：邏輯主文件（即數據的一個邏輯組合，它可能是大型數據庫的一部分或是一個獨立的文件）的數目。（5）外部接口數：機器可讀的全部接口（例如，磁盤或磁帶上的數據文件）的數量，用這些接口把信息傳送給另一個系統。信息域的5個特性2.估算功能點的步驟用下述3個步驟，可估算出一個軟件的功能點數（即軟件規模）。（1）計算未調整的功能點數UFP（ai是信息域特性系數）(2)計算技術復雜性因子TCF（3）計算功能點數FP用下式計算功能點數FP：FP=UFP×TCFUFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×InfTCF=0.65+0.01×DIDI=表13.1信息域特性系數值復雜級別特性系統簡單平均復雜輸入系數a1345輸出系數a2457查詢系數a3346文件系數a471015接口系數a55710表13.2技術因素序號Fi技術因素序號Fi技術因素1F1數據通信8F8聯機更新2F2分布式數據處理9F9復雜的計算3F3性能標準10F10可重用性4F4高負荷的硬件11F11安裝方便5F5高處理率12F12操作方便6F6聯機數據輸入13F13可移值性7F7終端用戶效率14F14可維護性13.2工作量估算軟件估算模型使用由經驗導出的公式來預測軟件開發工作量，工作量是軟件規模（KLOC或FP）的函數，工作量的單位通常是人月（pm)。支持大多數估算模型的經驗數據，都是從有限個項目的樣本集中總結出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開發環境。13.2.1靜態單變量模型這類模型的總體結構形式如下：E=A+B×(ev)C其中，A、B和C是由經驗數據導出的常數，E是以人月為單位的工作量，ev是估算變量（KLOC或FP）。下面給出幾個典型的靜態單變量模型。1.面向KLOC的估算模型(1)Walston_Felix模型E=5.2×(KLOC)0.91(2)Bailey_Basili模型E=5.5+0.73×(KLOC)1.16(3)Boehm簡單模型E=3.2×(KLOC)1.05(4)Doty模型（在KLOC>9時適用）E=5.288×(KLOC)1.0472.面向FP的估算模型(1)Albrecht&Gaffney模型E=-13.39+0.0545FP(2)Maston,Barnett和Mellichamp模型E=585.7+15.12FP13.2.2動態多變量模型動態多變量模型也稱為軟件方程式，它是根據從4000多個當代軟件項目中收集的生產率數據推導出來的。該模型把工作量看作是軟件規模和開發時間這兩個變量的函數。動態多變量估算模型的形式如下：E=(LOC×B0.333/P)3×(1/t)4 (13.2)其中，E是以人月或人年為單位的工作量；t是以月或年為單位的項目持續時間；13.2.3COCOMO2模型

COCOMO是構造性成本模型（constructivecostmodel)的英文縮寫。1981年Boehm在《軟件工程經濟學》中首次提出了COCOMO模型，本書第三版曾對此模型作了介紹。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經驗。

COCOMO2給出了3個層次的軟件開發工作量估算模型，這3個層次的模型在估算工作量時，對軟件細節考慮的詳盡程度逐級增加。這些模型既可以用于不同類型的項目，也可以用于同一個項目的不同開發階段。這3個層次的估算模型分別是：

（1）應用系統組成模型。這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。（2）早期設計模型。這個模型適用于體系結構設計階段。（3）后體系結構模型。這個模型適用于完成體系結構設計之后的軟件開發階段。下面以后體系結構模型為例，介紹COCOMO2模型。該模型把軟件開發工作量表示成代碼行數（KLOC）的非線性函數：

E=

(13.3)其中，E是開發工作量（以人月為單位），a是模型系數，KLOC是估計的源代碼行數（以千行為單位），b是模型指數，fi(i=1~17)是成本因素（成本因素及工作量系數表見P310）COCOMO2使用的5個分級因素：項目先例性開發靈活性風險排除性項目組凝聚力過程成熟度13.3進度計劃不論從事哪種技術性項目，實際情況都是，在實現一個大目標之前往往必須完成數以百計的小任務（也稱為作業）。項目管理者的目標是定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發現拖延進度的情況。為達到上述目標，管理者必須制定一個足夠詳細的進度表，以便監督項目進度并控制整個項目。13.3.1估算開發時間估算出完成給定項目所需的總工作量之后，接下來需要回答的問題就是：用多長時間才能完成該項目的開發工作？對于一個估計工作量為20人月的項目，可能想出下列幾種進度表：1個人用20個月完成該項目；4個人用5個月完成該項目；20個人用1個月完成該項目。但是，這些進度表并不現實，實際上軟件開發時間與從事開發工作的人數之間并不是簡單的反比關系。通常，成本估算模型也同時提供了估算開發時間T的方程。與工作量方程不同，各種模型估算開發時間的方程很相似，例如：(1)Walston_Felix模型T=2.5E0.35(2)原始的COCOMO模型T=2.5E0.38(3)COCOMO2模型T=3.0E0.33+0.2×(b-1.01)(4)Putnam模型T=2.4E1/3其中，E是開發工作量（以人月為單位），T是開發時間（以月為單位）。用上列方程計算出的T值，代表正常情況下的開發時間。客戶往往希望縮短軟件開發時間，顯然，為了縮短開發時間應該增加從事開發工作的人數。但是，經驗告訴我們，隨著開發小組規模擴大，個人生產率將下降，以致開發時間與從事開發工作的人數并不成反比關系。13.3.2Gantt圖

Gantt（甘特）圖是歷史悠久、應用廣泛的制定進度計劃的工具，下面通過一個非常簡單的例子介紹這種工具。假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步完成：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工作，然而工具卻很有限：只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢?表13.5各道工序估計需用的時間(小時）圖13.1舊木板房刷漆工程的Gantt圖工序墻壁刮舊漆刷新漆清理1或32312或446213.3.3工程網絡Gantt圖也有3個主要缺點：(1)不能顯式地描繪各項作業彼此間的依賴關系；(2)進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；(3)計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。當把一個工程項目分解成許多子任務，并且它們彼此間的依賴關系又比較復雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節省資源又保證進度的計劃，而且還容易發生差錯。工程網絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業的開始時間和結束時間，此外，它還顯式地描繪各個作業彼此間的依賴關系。圖13.2舊木板房刷漆工程的工程網絡在工程網絡中用箭頭表示作業(例如，刮舊漆，刷新漆，清理等)，用圓圈表示事件(一項作業開始或結束)。1-2刮第1面墻上的舊漆2-3刮第2面墻上的舊漆2-4刷第1面墻上的新漆。。。。。（虛線表示并不存在的作業，是為了顯式地表示作業之間的依賴關系）13.3.4估算工程進度首先，把每個作業估計需要使用的時間寫在表示該項作業的箭頭上方。注意，箭頭長度和它代表的作業持續時間沒有關系，箭頭僅表示依賴關系，它上方的數字才表示作業的持續時間。其次，為每個事件計算下述兩個統計數字。圖13.3舊木板房刷漆工程的完整的工程網絡（PERT圖）1-2刮第1面墻上的舊漆2-3刮第2面墻上的舊漆2-4刷第1面墻上的新漆。。。。。（虛線表示并不存在的作業，是為了顯式地表示作業之間的依賴關系）13.3.5關鍵路徑圖13.3中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。關鍵路徑上的事件(關鍵事件)必須準時發生，組成關鍵路徑的作業(關鍵作業)的實際持續時間不能超過估計的持續時間，否則工程就不能準時結束。工程項目的管理人員應該密切注視關鍵作業的進展情況，如果關鍵事件出現的時間比預計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關鍵作業中增加資源才會有效果。13.3.6機動時間一個作業可以有的全部機動時間等于它的結束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業的持續時間：機動時間=(LET)結束-(EET)開始-持續時間對于前述油漆舊木板房的例子，計算得到的非關鍵作業的機動時間列在表13.6（見書308頁）中。圖13.4舊木板房刷漆工程改進的Gantt圖之一13.4人員組織軟件項目成功的關鍵是有高素質的軟件開發人員。然而大多數軟件的規模都很大，單個軟件開發人員無法在給定期限內完成開發工作，因此，必須把多名軟件開發人員合理地組織起來，使他們有效地分工協作共同完成開發工作。下面介紹3種典型的組織方式：民主制程序員組主程序員組現代程序員組13.5質量保證概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特征相一致的程度。上述定義強調了下述的3個要點：（1）軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。（2）指定的開發標準定義了一組指導軟件開發的準則，如果沒有遵守這些準則，幾乎肯定會導致軟件質量不高。（3）通常，有一組沒有顯式描述的隱含需求（例如，軟件應該是容易維護的）。13.5.1軟件質量圖13.9軟件質量因素與產品活動的關系13.5.2軟件質量保證措施軟件質量保證（softwarequalityassurance,SQA）的措施主要有：基于非執行的測試（也稱為復審或評審），基于執行的測試（即以前講過的軟件測試）和程序正確性證明。復審主要用來保證在編碼之前各階段產生的文檔的質量；基于執行的測試需要在程序編寫出來之后進行，它是保證軟件質量的最后一道防線；程序正確性證明使用數學方法嚴格驗證程序是否與對它的說明完全一致。1.技術復審的必要性2.走查3.審查4.程序正確性證明13.6軟件配置管理軟件配置管理是在軟件的整個生命期內管理變化的一組活動。具體地說，這組活動用來：①標識變化；②控制變化；③確保適當地實現了變化；④向需要知道這類信息的人報告變化。軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發生的，而配置管理是在軟件項目啟動時就開始，并且一直持續到軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。13.6.1軟件配置1.軟件配置項軟件過程的輸出信息可以分為3類：

①計算機程序（源代碼和可執行程序）；

②描述計算機程序的文檔（供技術人員或用戶使用）；③數據（程序內包含的或在程序外的）。上述這些項組成了在軟件過程中產生的全部信息，我們把它們統稱為軟件配置，而這些項就是軟件配置項。2.基線基線是一個軟件配置管理概念，它有助于我們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為：已經通過了正式復審的規格說明或中間產品，它可以作為進一步開發的基礎，并且只有通過正式的變化控制過程才能改變它。簡而言之，基線就是通過了正式復審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現變化，但是，必須應用特定的、正式的過程（稱為規程）來評估、實現和驗證每個變化。13.6.2軟件配置管理過程軟件配置管理是軟件質量保證的重要一環，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發生的任何變化的報告。具體來說，軟件配置管理主要有5項任務：標識、版本控制、變化控制、配置審計和報告。13.7能力成熟度模型美國卡內基梅隆大學軟件工程研究所在美國國防部資助下于20世紀80年代末建立的能力成熟度模型（capabilitymaturitymodel，CMM)，是用于評價軟件機構的軟件過程能力成熟度的模型。最初，建立此模型的目的主要是，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據，發展到后來，此模型又同時被應用于許多軟件機構內部的過程改進活動中。CMM通過定義能力成熟度的5個等級，引導軟件開發機構不斷識別出其軟件過程的缺陷，并指出應該做哪些改進，但是，它并不提供做這些改進的具體措施。能力成熟度的5個等級從低到高依次是：初始級（又稱為1級），可重復級（又稱為2級），已定義級（又稱為3級），已管理級（又稱為4級）和優化級（又稱為5級）。下面介紹這5個級別的特點。CMM通過定義能力成熟度的5個等級，引導軟件開發機構不斷識別出其軟件過程的缺陷，并指出應該做哪些改進，但是，它并不提供做這些改進的具體措施。能力成熟度的5個等級從低到高依次是：初始級（又稱為1級），可重復級（又稱為2級），已定義級（又稱為3級），已管理級（又稱為4級）優化級（又稱為5級）。1.初始級軟件過程的特征是無序的，有時甚至是混亂的。幾乎沒有什么過程是經過定義的（即沒有一個定型的過程模型），項目能否成功完全取決于開發人員的個人能力。處于這個最低成熟度等級的軟件機構，基本上沒有健全的軟件工程管理制度，其軟件過程完全取決于項目組的人員配備，所以具有不可預測性，人員變了過程也隨之改變。如果一個項目碰巧由一個杰出的管理者和一支有經驗、有能力的開發隊伍承擔，則這個項目可能是成功的。但是，更常見的情況是，由于缺乏健全的管理和周密的計劃，延期交付和費用超支的情況經常發生，結果，大多數行動只是應付危機，而不是完成事先計劃好的任務。總之，處于1級成熟度的軟件機構，其過程能力是不可預測的，其軟件過程是不穩定的，產品質量只能根據相關人員的個人工作能力而不是軟件機構的過程能力來預測。2.可重復級軟件機構建立了基本的項目管理過程(過程模型),可跟蹤成本、進度、功能和質量。已經建立起必要的過程規范，對新項目的策劃和管理過程是基于以前類似項目的實踐經驗，使得有類似應用經驗的軟件項目能夠再次取得成功。達到2級的一個目標是使項目管理過程穩定，從而使得軟件機構能重復以前在成功項目中所進行過的軟件項目工程實踐。處于2級成熟度的軟件機構，項目負責人跟蹤軟件產品開發的成本和進度以及產品的功能和質量，并且識別出為滿足約束條件所應解決的問題。已經做到軟件需求條理化，而且其完整性是受控制的。已經制定了項目標準，并且軟件機構能確保嚴格執行這些標準。項目組與客戶及承包商已經建立起一個穩定的、可管理的工作環境。處于2級成熟度的軟件機構的過程能力可以概括為軟件項目的策劃和跟蹤是穩定的，已經為一個有紀律的管理過程提供了可重復以前成功實踐的項目環境。軟件項目工程活動處于項目管理體系的有效控制之下，執行著基于以前項目的準則且合乎現實的計劃。3.已定義級軟件機構已經定義了完整的軟件過程（過程模型），軟件過程已經文檔化和標準化。所有項目組都使用文檔化的、經過批準的過程來開發和維護軟件。這一級包含了第2級的全部特征。在第3級成熟度的軟件機構中，有一個固定的過程小組從事軟件過程工程活動。當需要時，過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟件項目的過程實例，并投入過程運作而開展有效的軟件項目工程實踐。同時，過程小組還可以推進軟件機構的過程改進活動。在該軟件機構內實施了培訓計劃，能夠保證全體項目負責人和項目開發人員具有完成承擔的任務所要求的知識和技能。處于3級成熟度的軟件機構的過程能力可以概括