軟件工程13-軟件項目管理

軟件工程

岐兵Email:1可行性研究需求分析概要設(shè)計詳細(xì)設(shè)計實現(xiàn)集成測試確認(rèn)測試使用與維護(hù)退役軟件定義軟件開發(fā)軟件使用與維護(hù)軟件生命周期軟件項目管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達(dá)到既定目標(biāo)的過程軟件項目管理先于任何技術(shù)活動之前開始，并且貫穿于軟件的整個生命周期之中軟件項目管理過程從一組項目計劃活動開始，而制定計劃的基礎(chǔ)是工作量估算和完成期限估算軟件項目管理軟件項目管理

(SoftwareManagement)經(jīng)理管什么？計劃預(yù)算組織進(jìn)度標(biāo)準(zhǔn)4課程內(nèi)容提綱第13章：“軟件項目管理”估算軟件規(guī)模開發(fā)工作量估算進(jìn)度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型估算軟件規(guī)模代碼行技術(shù)代碼行技術(shù)是比較簡單的定量估算軟件規(guī)模的方法。這種方法依據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷史數(shù)據(jù)估計實現(xiàn)一個功能所需要的源程序行數(shù)把實現(xiàn)每個功能所需要的源程序行數(shù)累加起來標(biāo)準(zhǔn)值法（三點法）為了使得對程序規(guī)模的估計值更接近實際值，可以由多名有經(jīng)驗的軟件工程師分別做出估計。每個人都估計程序的最小規(guī)模(a)、最大規(guī)模(b)和最可能的規(guī)模(m),分別算出這3種規(guī)模的平均值a,b,c之后，再用下式計算程序規(guī)模的估計值：代碼行數(shù)(LOC)，千行代碼數(shù)(KLOC)代碼行技術(shù)的主要優(yōu)點代碼是所有軟件開發(fā)項目都有的“產(chǎn)品”，而且很容易計算代碼行數(shù)代碼行技術(shù)的缺點是源程序僅是軟件配置的一個成分，用它的規(guī)模代表整個軟件的規(guī)模似乎不太合理；用不同語言實現(xiàn)同一個軟件所需要的代碼行數(shù)并不相同,這種方法不適用于非過程語言。估算軟件規(guī)模功能點技術(shù)功能點技術(shù)依賴對軟件信息域特性和軟件復(fù)雜性的評估結(jié)果，估算軟件規(guī)模。1信息域特性輸入項數(shù)(Inp)：用戶向軟件輸入的項數(shù)，這些輸入給軟件提供面向應(yīng)用的數(shù)據(jù)。輸出項數(shù)(Out)：軟件向用戶輸出的項數(shù)，它們向用戶提供面向應(yīng)用的信息，例如，報表和出錯信息等。報表內(nèi)的數(shù)據(jù)項不單獨計數(shù)。估算軟件規(guī)模查詢數(shù)(Inq)：查詢即是一次聯(lián)機(jī)輸入，它導(dǎo)致軟件以聯(lián)機(jī)輸出方式產(chǎn)生某種即時響應(yīng)。主文件數(shù)(Maf)：邏輯主文件(即數(shù)據(jù)的一個邏輯組合，它可能是大型數(shù)據(jù)庫的一部分或是一個獨立的文件)的數(shù)目。外部接口數(shù)(Inf)：機(jī)器可讀的全部接口(例如，磁盤或磁帶上的數(shù)據(jù)文件)的數(shù)量，用這些接口把信息傳送給另一個系統(tǒng)。估算軟件規(guī)模估算功能點的步驟用下述3個步驟，可估算出一個軟件的功能點數(shù)(即軟件規(guī)模)(1)計算未調(diào)整的功能點數(shù)UFP把lnp、Out、lnq、Maf和Inf分為簡單級、平均級或復(fù)雜級，并根據(jù)其等級為每個特性分配一個功能點數(shù)。計算未調(diào)整的功能點數(shù)UFP：UFP=a1

lnp+a2Out+a3Inq+a4Maf+a5Inf

ai(1≤i≤5)是信息域特性系數(shù)．其值由相應(yīng)特性的復(fù)雜級別決定，如下表所示:估算軟件規(guī)模

復(fù)雜級別特性系數(shù)簡單平均復(fù)雜輸入系數(shù)a1346輸出系數(shù)a2457查詢系數(shù)a3346文件系數(shù)a471015接口系數(shù)a55710估算軟件規(guī)模(2)計算技術(shù)復(fù)雜性因子TCF這一步度量14種技術(shù)因素對軟件規(guī)模的影響程度。這些因素包括高處理率、性能標(biāo)準(zhǔn)(例如，響應(yīng)時間)、聯(lián)機(jī)更新等，在表13．2中列出了全部技術(shù)因素，并用Fi，(1

i

14)代表這些因素。根據(jù)軟件的特點，為每個因素分配一個從0到5的值。計算技術(shù)因素對軟件規(guī)模的綜合影響程度DI：ID=Fi;ID的值在0-70之間計算技術(shù)復(fù)雜因子TCFTCF=0.65+0.01ID；TCF的值在0.65-1.35之間估算軟件規(guī)模序號Fi技術(shù)因數(shù)序號Fi技術(shù)因數(shù)1F1數(shù)據(jù)通信8F8聯(lián)機(jī)更新2F2分布式數(shù)據(jù)處理9F9復(fù)雜的計算3F3性能標(biāo)準(zhǔn)10F10可重用性4F4高負(fù)荷的硬件11F11安裝方便5F5高處理率12F12操作方便6F6聯(lián)機(jī)數(shù)據(jù)輸入13F13可移植性7F7終端用戶效率14F14可維護(hù)性估算軟件規(guī)模(3)計算功能點數(shù)FPFP＝UFP×TCF功能點數(shù)與所用的編程浯言無關(guān)在判斷信息域特性復(fù)雜級別和技術(shù)因素的影響程度時，存在著相當(dāng)大的主觀因素。估算軟件規(guī)模課程內(nèi)容提綱第13章：“軟件項目管理”估算軟件規(guī)模開發(fā)工作量估算進(jìn)度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型－軟件估算模型使用由經(jīng)驗導(dǎo)出的公式來預(yù)測軟件開發(fā)工作量，工作量是軟件規(guī)模（KLOC或FP）的函數(shù)，工作量的單位通常是人月(pm)大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個項目的樣本集中總結(jié)出來的沒有一個估算模型可以適用于所有類型的軟件和開發(fā)環(huán)境開發(fā)工作量估算靜態(tài)單變量模型總體結(jié)構(gòu)形式E=A+B(ev)cA、B和C是由經(jīng)驗數(shù)據(jù)導(dǎo)出的常數(shù)，E是以人月為單位的工作量，ev是估算變量(KLOC或FP)幾個典型的靜態(tài)單變量模型1面向KLOC的估算模型(1)Walston_Felix模型

E=5.2(KLOC)0.91(2)BaileyBasili模型

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.047開發(fā)工作量估算2面向FP的估算模型(1)Albrecht&Gaffney模型

E＝-13.39+0.0545FP(2)Maston，Barnett和Mellichamp模型

E＝585.7+15.12FP對于相同的KLOC或FP值，用不同模型估算將得出不同的結(jié)果。主要原因是這些模型多數(shù)都是僅根據(jù)若干應(yīng)用領(lǐng)域中有限個項目的經(jīng)驗數(shù)據(jù)推導(dǎo)出來的，適用范圍有限必須根據(jù)當(dāng)前項目的特點選擇適用的估算模型，并且根據(jù)需要適當(dāng)?shù)卣{(diào)整(例如，修改模型常數(shù))估算模型。開發(fā)工作量估算動態(tài)多變量模型動態(tài)多變量模型也稱為軟件方程式，它是根據(jù)從4000多個當(dāng)代軟件項目中收集的生產(chǎn)率數(shù)據(jù)推導(dǎo)出來的。該模型把工作量看作是軟件規(guī)模和開發(fā)時間這兩個變量的函數(shù)。動態(tài)多變量估算模型的形式如下：

E=(LOCB0.333/P)3(1/t)4E是以人月或人年為單位的工作量，t是以月或年為單位的項目持續(xù)時間；B是特殊技術(shù)因子，它隨著對測試、質(zhì)量保證、文檔及管理技術(shù)的需求的增加而緩慢增加，對于較小的程序(KLOC＝5-15)，B＝0.16，對于超過70KLOC的程序，B=0.39；開發(fā)工作量估算P是生產(chǎn)率參數(shù)，它反映了下述因素對工作量的影響：總體過程成熟度及管理水平使用良好的軟件工程實踐的程度使用的程序設(shè)計語言的級別軟件環(huán)境的狀態(tài)軟件項目組的技術(shù)及經(jīng)驗應(yīng)用系統(tǒng)的復(fù)雜程度開發(fā)實時嵌入式軟件時，P的典型值為2000；開發(fā)電信系統(tǒng)和系統(tǒng)軟件時，P=10000；對于商業(yè)應(yīng)用系統(tǒng)來說．P=28000。可以從歷史數(shù)據(jù)導(dǎo)出適用于當(dāng)前項目的生產(chǎn)率參數(shù)值。開發(fā)工作量估算COCOMO2模型COCOMO是構(gòu)造性成本模型(constructivecostmodel)的縮寫1981年Boehm在《軟件工程經(jīng)濟(jì)學(xué)》中首次提出COCOMO模型1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經(jīng)驗。COCOMO2給出了3個層次的開發(fā)工作量估算模型這3個層次的模型在估算工作量時，對軟件細(xì)節(jié)考慮的詳盡程度逐級增加。這些模型既可以用于不同類型的項目，也可用于同一個項目的不同開發(fā)階段開發(fā)工作量估算COCOMO2三個層次的估算模型分別是應(yīng)用系統(tǒng)組成模型這個模型主要用于估算構(gòu)建原型的工作量，模型名字暗示在構(gòu)建原型時大量使用已有的構(gòu)件。早期設(shè)計模型這個模型適用于體系結(jié)構(gòu)設(shè)計階段。后體系結(jié)構(gòu)模型這個模型適用于完成體系結(jié)構(gòu)設(shè)計之后的軟件開發(fā)階段。開發(fā)工作量估算COCOMO2模型把軟件開發(fā)工作量表示成代碼行數(shù)（KLOC）的非線性函數(shù)：

17 E=aKLOCbfi

i=1E是開發(fā)工作量（以人月為單位）a是模型系數(shù)KLOC是估計的源代碼行數(shù)（以千行為單位）b是模型指數(shù)fi（i＝1-17）是成本因素開發(fā)工作量估算Boehm把成本因素劃分成產(chǎn)品因素、平臺因素、人員因素和項目因素等4類。表13．3列出了COCOMO2模型使用的成本因素及與之相聯(lián)系的工作量系數(shù)。與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化，這些變化反映了在過去十幾年中軟件行業(yè)取得的巨大進(jìn)步。開發(fā)工作量估算(1)新增加了4個成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續(xù)性(即人員穩(wěn)定程度)和多地點開發(fā)。(2)略去了原始模型中的2個成本因素(計算機(jī)切換時間和使用現(xiàn)代程序設(shè)計實踐)?，F(xiàn)在，開發(fā)人員普遍使用工作站開發(fā)軟件，批處理的切換時間已經(jīng)不再是問題。(3)某些成本因素(分析員能力、平臺經(jīng)驗、語言和工具經(jīng)驗)對生產(chǎn)率的影響(即工作量系數(shù)最大值與最小值的比率)增加了，另一些成本因素(程序員能力)的影響減小了。開發(fā)工作量估算為了確定工作量方程中模型指數(shù)b的值，COCOMO2采用了更加精細(xì)得多的b分級模型，這個模型使用5個分級因素Wi，(1≤i≤5)其中每個因素都劃分成從甚低(Wi=5)到特高(Wi＝0)的6個級別。然后用下式計算b的數(shù)值：

b=1.01+0.01

Wib的取值范圍為1.01-1.26。開發(fā)工作量估算COCOMO2使用的5個分組因素如下所述；(1)項目先例性。這個分級因素指出，對于開發(fā)組織來說該項目的新奇程度。(2)開發(fā)靈活性。這個分級因素反映出，為了實現(xiàn)預(yù)先確定的外部接口需求及為了及早開發(fā)出產(chǎn)品而需增加的工作量。(3)風(fēng)險排除度。這個分級因素反映了重大風(fēng)險已被消除的比例。在多數(shù)情況下，這個比例和指定了重要模塊接口(即選定了體系結(jié)構(gòu))的比例密切相關(guān)。(4)項目組凝聚力。這個分級因素表明了開發(fā)人員相互協(xié)作時可能存在的困難。這個因素反映了開發(fā)人員在目標(biāo)和文化背景等方面相一致的程度，以及開發(fā)人員組成一個小組工作的經(jīng)驗。(5)過程成熟度。這個分級因素反映了按照CMM(見13．7節(jié))度量出的項目組織的過程成熟度。開發(fā)工作量估算在原始的COCOMO模型中，僅粗略地考慮了前兩個分級因素對指數(shù)b之值的影響。工作量方程中模型系數(shù)a的典型值為3.0，在實際工作中應(yīng)該根據(jù)歷史經(jīng)驗數(shù)據(jù)確定一個適合本組織當(dāng)前開發(fā)的項目類型的數(shù)值。開發(fā)工作量估算課程內(nèi)容提綱第13章：“軟件項目管理”估算軟件規(guī)模開發(fā)工作量估算進(jìn)度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型項目進(jìn)度計劃項目管理者的目標(biāo)是定義全部項目任務(wù)，識別出關(guān)鍵任務(wù)，跟蹤關(guān)鍵任務(wù)的進(jìn)展?fàn)顩r，以保證能及時發(fā)現(xiàn)拖延進(jìn)度的情況。為達(dá)到上述目標(biāo)，管理者必須制定一個足夠詳細(xì)的進(jìn)度表，以便監(jiān)督項目進(jìn)度并控制整個項目。軟件項目的進(jìn)度安排是這樣一種活動，它通過把工作量分配給特定的軟件工程任務(wù)并規(guī)定完成各項任務(wù)的起止日期，從而將估算出的項目工作量分布于計劃好的項日持續(xù)期內(nèi)。進(jìn)度計劃將隨著時間的流逝而不斷演化。進(jìn)度計劃估算開發(fā)時間估算出完成給定項目所需的總工作量之后接下來需要回答的問題就是：用多長時間才能完成該項目的開發(fā)工作?對于一個估計工作量為20人月的項目，可能想出下列幾種進(jìn)度表：1個人用20個月完成該項目，4個人用5個月完成該項目；20個人用1個月完成該項目．實際上軟件開發(fā)時間與從事開發(fā)工作的人數(shù)之間并不是簡單的反比關(guān)系。進(jìn)度計劃通常，成本估算模型也同時提供了估算開發(fā)時間T的方程與工作量方程不同，各種模型估算開發(fā)時間的方程很相似例如：Walston-Felix模型 T=2.5E0.35原始的COCOMO模型

T=2.5E0.38

COCOMO2模型 T=3.0E0.33+0.2*(b-1.01)Putnam模型 T=2.4E1/3E是開發(fā)工作量(以人月為單位)，T是開發(fā)時間(以月為單位)。

進(jìn)度計劃開發(fā)時間與從事開發(fā)工作的人數(shù)并不成反比關(guān)系。出現(xiàn)這種現(xiàn)象主要有下述兩個原因：當(dāng)小組變得更大時，每個人需要用更多時間與組內(nèi)其他成員討論問題、協(xié)調(diào)工作，增加了通信開銷。如果在開發(fā)過程中增加小組人員，則最初一段時間內(nèi)項目組總生產(chǎn)率不僅不會提高反而會下降。這是因為新成員在開始時不僅不是生產(chǎn)力，而且在他們學(xué)習(xí)期間還需要花費小組其他成員的時間．綜合上述兩個原因，存在被稱為Brooks規(guī)律的下述現(xiàn)象：向一個已經(jīng)延期的項目增加人力，只會使它更延期。進(jìn)度計劃項目組規(guī)模與項目組總生產(chǎn)率的關(guān)系如果項目組共有P名組員，每個組員必須與所有其他組員通信以協(xié)調(diào)開發(fā)活動，則通信路徑數(shù)為P(P-1)／2。如果每個組員只需與另外一個組員通信，則通信路徑數(shù)為P-1。通信路徑數(shù)大約在P-P2／2的范圍內(nèi)變化。組員個人平均生產(chǎn)率為Lr=L-l(P-1)r,r是對通信路徑數(shù)的度量對于一個規(guī)模為P的項目組,項目組的總生產(chǎn)率為Ltot=P(L-l(P-1)r)對于給定的一組L，P和r的值，總生產(chǎn)率是項目組規(guī)模P的函數(shù)。隨著P值增加，將從0增大到某個最大值，然后再下降。因此，存在一個最佳的項目組規(guī)模Popt,這個規(guī)模的項目組其總生產(chǎn)率最高。進(jìn)度計劃舉例假設(shè)個人最高生產(chǎn)率為500LOC／月(即L＝500)，每條通信路徑導(dǎo)致生產(chǎn)率下降10％(即＝50)。如果每個組員都必須與組內(nèi)所有其他組員通信(r＝1)，則項目組規(guī)模與生產(chǎn)率的關(guān)系列在表13．4中，可見，在這種情況下項目組的最佳規(guī)模是5.5人。Boehm根據(jù)經(jīng)驗指出，軟件項目的開發(fā)時間最多可以減少到正常開發(fā)時間的75％。如果要求一個軟件系統(tǒng)的開發(fā)時間過短，則開發(fā)成功的概率幾乎為零。進(jìn)度計劃項目組規(guī)模個人生產(chǎn)率總生產(chǎn)率150050024509003400120043501400530015005.52751512625015007200140081501200進(jìn)度計劃Gantt圖例:重新油漆一座矩形木板房，具體工作可分為三步完成。首先刮掉舊漆，然后刷上新漆，最后清理濺在窗戶上的油漆。15名工人去完成這項工作，規(guī)定有：5把刮漆用的刮板；5把刷漆用的刷子；5把清除濺在窗戶上油漆用的小刮刀。進(jìn)度計劃板房的第2、4兩面墻的長度為第1、3兩面墻的長度的2倍。2134

一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這種方法效率最低，因為15名工人中由于工具的限制，所安排的工作在任何時候都有10名工人閑著沒活干，完成全部工程需要36小時。進(jìn)度計劃各工序所需時間

工序時間墻壁刮舊漆刷新漆清理1(3)2(4)3(6)1(2)2(4)4(8)6(12)2(4)進(jìn)度計劃

另一種做法是采用“流水作業(yè)法”，即先由5名工人用刮板刮掉第一面墻上的舊漆(另外10名工人休息)，當(dāng)?shù)谝幻鎵蝺艉?，另?名工人立即用刷子給這面墻刷新漆(與此同時拿刮板的5名工人轉(zhuǎn)去刮第二面墻上的舊漆)，一旦刮舊漆的工人轉(zhuǎn)到第三面墻而且刷新漆的工人轉(zhuǎn)到第二面墻以后，余下的5名工人立即拿起刮刀去清除濺在第一面墻窗戶上的油漆。這種安排每個工人都有活干，可在22小時結(jié)束全部工程。進(jìn)度計劃246810121416182022刮舊漆刷新漆清理時間作業(yè)舊木板房刷漆工程的Gantt圖進(jìn)度計劃Gantt圖能很形象地描繪任務(wù)分解情況，以及每個子任務(wù)的開始和結(jié)束時間，但它也存在以下不足：

1不能顯式地描繪各作業(yè)彼此間的依賴關(guān)系；

2進(jìn)度計劃的關(guān)鍵部分不明確，難于判定哪些部分應(yīng)當(dāng)是主攻和控制的對象；

3計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。進(jìn)度計劃工程網(wǎng)絡(luò)工程網(wǎng)絡(luò)是判定進(jìn)度計劃時另一種常用的圖形工具，它同樣能描繪任務(wù)分解情況以及每項作業(yè)的開始時間和結(jié)束時間。它還顯式地描繪各個作業(yè)彼此間的依關(guān)系。在工程網(wǎng)絡(luò)圖中，用箭頭表示作業(yè)用圓圈表示事件(一項作業(yè)開始或結(jié)束)事件僅僅是可以明確定義的時間點，它并不消耗時間和資源。作業(yè)通常既消耗資源又需要持續(xù)一定的時間進(jìn)度計劃1235810114679刮舊漆刷新漆清理工程網(wǎng)絡(luò)圖中引入虛擬作業(yè)為了顯式地表示作業(yè)之間的依賴關(guān)系例如，事件3和事件4之間有依賴關(guān)系，作業(yè)2—3刮第2面墻上舊漆是作業(yè)4—6給第2面墻刷新漆的前道工序，只有完成前者，后者才能開始，虛擬作業(yè)3—4明確地表示了這種依賴關(guān)系。進(jìn)度計劃估算工程進(jìn)度1把每個作業(yè)估計需要使用的時間寫在該作業(yè)箭頭上2為每個事件計算兩個數(shù)字：EET(最早時刻)和LET(最遲時刻)，分別寫在事件圓圈的右上角和右下角持續(xù)時間EETLET最早時刻最遲時刻事件號進(jìn)度計劃事件的最早時刻EET是該事件可以發(fā)生的最早時間通常工程網(wǎng)絡(luò)中第一個事件的最早時刻定義為零其他事件的最早時刻在工程網(wǎng)絡(luò)上從左至右按事件發(fā)生順序計算。計算最早時刻EET使用下述三條簡單規(guī)則為：1考慮進(jìn)入該事件的所有作業(yè)2對每個作業(yè)都計算它的持續(xù)時間與起始事件的EET之和3取上述和數(shù)中的最大值作為該事件的最早時刻EET例如，事件4的最早時刻為：

EET=max{2+3,6+0}=6進(jìn)度計劃事件的最遲時刻LET是在不影響工程峻工時間的前提下，該事件最晚可以發(fā)生的時刻。一般最后一個事件(工程結(jié)束)的最遲時刻就是它的最早時刻其他事件的最遲時刻在工程網(wǎng)絡(luò)上從右至左按逆作業(yè)流的方向計算計算最遲時刻LET使用以下三條規(guī)則：1考慮離開該事件的所有作業(yè)；2從每個作業(yè)的結(jié)束事件的最遲時刻中減去該作業(yè)的持續(xù)時間；3選取上述差數(shù)中的最小值作為該事件的最遲時刻LET。例如，事件8的最遲時刻為：

LET=min{21-6,20-0}=15進(jìn)度計劃1235476891011002266811151512126612181520212123232(0)4(0)2(3)4(3)6(0)3(1)1(11)2(6)1(5)2(0)0(4)0(6)0(5)0(0)6(0)3(0)關(guān)鍵路徑關(guān)鍵路徑是由最早時刻=最遲時刻的那些事件組成的路徑集合，在圖中關(guān)鍵路徑用粗線箭頭表示。關(guān)鍵路徑上的事件(關(guān)鍵事件)必須準(zhǔn)時發(fā)生，組成關(guān)鍵路徑的作業(yè)(關(guān)鍵作業(yè))的實際持續(xù)時間不能超過估計的持續(xù)時間，否則工程就不可能準(zhǔn)時結(jié)束。工程項目的管理人員應(yīng)該密切注視關(guān)鍵作業(yè)的進(jìn)展情況，如果關(guān)鍵事件出現(xiàn)的時間比預(yù)計的時間晚，則會使最終完成項目的時間拖后；如果我們希望縮短工期，只有往關(guān)鍵作業(yè)中增加資源才會有效果。進(jìn)度計劃1235476891011002266811151512126612181520212123232(0)4(0)2(3)4(3)6(0)3(1)1(11)2(6)1(5)2(0)0(4)0(6)0(5)0(0)6(0)3(0)機(jī)動時間不在關(guān)鍵路徑上的作業(yè)有一定程度的機(jī)動余地，也就是說實際開始時間可以比預(yù)定時間晚一些，或者實際持續(xù)時間可以比預(yù)計的持續(xù)時間長一些，而并不影響工程的結(jié)束時間。一個作業(yè)擁有的全部機(jī)動時間可按下式計算：機(jī)動時間=(LET)結(jié)束－

(EET)開始－持續(xù)時間

進(jìn)度計劃工程網(wǎng)絡(luò)的特點是可以顯示地定義事件及作業(yè)之間的依賴關(guān)系而Cantt圖的特點是簡單，直觀，為更多的人所熟悉實際使用時如能將這兩種工具相結(jié)合制訂和管理進(jìn)度計劃，則可起到互相補(bǔ)充，取長補(bǔ)短進(jìn)度計劃計劃和管理的基本方法仍然是自頂向下分解，把項目分解為若干個階段，每個階段再分解成許多更小的任務(wù)，每個任務(wù)又可進(jìn)一步分解為若干個步驟等等利用工程網(wǎng)絡(luò)圖和Gantt圖可以制訂出合理的進(jìn)度計劃，科學(xué)地管理軟件開發(fā)工程的進(jìn)展情況進(jìn)度計劃GanttCharttw12345678ABCD當(dāng)前進(jìn)度優(yōu)點：簡單，能動態(tài)地反映開發(fā)進(jìn)展。缺點：難以反映多個任務(wù)間的邏輯關(guān)系。Gantt圖持續(xù)時間LastingTime機(jī)動時間SlackTime編號EarliestStartTimeLatestStartTime012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)標(biāo)出LastingTime(2)標(biāo)出EST:=從起點始，所有進(jìn)入事件的EST+LT中最大的(3)標(biāo)出LST:=從終點(EST=LST)始，所有離開事件的LSTLT中最小的(4)標(biāo)出ST:=終點LST

起點EST

LT(5)標(biāo)出CriticalPath:即EST=LST的所有事件組成的路徑工程網(wǎng)絡(luò)圖課程內(nèi)容提綱第13章：“軟件項目管理”估算軟件規(guī)模開發(fā)工作量估算進(jìn)度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型軟件項目組的組織方式組織軟件開發(fā)人員的方法，取決于所承擔(dān)的項目的特點、以往的組織經(jīng)驗以及管理者的看法和喜好下面介紹3種典型的組織方式1.民主制程序員組民主制程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協(xié)商做出技術(shù)決策。小組成員之間的通信是平行的。如果小組內(nèi)有n個成員，則可能的通信信道共有n(n一1)/2條。人員組織程序設(shè)計小組的規(guī)模應(yīng)該比較小，以2~8名成員為宜。如果項目規(guī)模很大，用一個小組不能在預(yù)定時間內(nèi)完成開發(fā)任務(wù)，則應(yīng)該使用多個程序設(shè)計小組，每個小組承擔(dān)工程項目的一部分任務(wù)，在一定程度上獨立自主地完成各自的任務(wù)系統(tǒng)的總體設(shè)計應(yīng)該能夠保證由各個小組負(fù)責(zé)開發(fā)的各部分之間的接口是良好定義的，并且是盡可能簡單的小組規(guī)模小，不僅可以減少通信問題，而且還有其他好處。例如，容易確定小組的質(zhì)量標(biāo)準(zhǔn)，而且用民主方式確定的標(biāo)準(zhǔn)更容易被大家遵守；組員間關(guān)系密切，能夠互相學(xué)習(xí)等等。人員組織民主制程序員組通常采用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內(nèi)其他成員完成同樣的任務(wù)。這樣的小組中，由全體討論協(xié)商決定應(yīng)該完成的工作，并且根據(jù)每個人的能力和經(jīng)驗分配適當(dāng)?shù)娜蝿?wù)。民主制程序員組的主要優(yōu)點是：組員們對發(fā)現(xiàn)程序錯誤持積極的態(tài)度組員們享有充分民主．小組有高度凝聚力缺點：由于沒有明確的權(quán)威指導(dǎo)開發(fā)工程的進(jìn)行，組員間將缺乏必要的協(xié)調(diào)，最終可能導(dǎo)致工程失敗人員組織2.主程序員組IBM公司在20世紀(jì)70年代初期開始采用主程序員組的組織方式采用這種組織方式主要出于下述幾點考慮軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗；程序設(shè)計過程中有許多事務(wù)性的工作，例如，大量信息的存儲和更新；多渠道通信很費時間，將降低程序員的生產(chǎn)率。人員組織主程序員組用經(jīng)驗多、技術(shù)好、能力強(qiáng)的程序員作為主程序員利用人和計算機(jī)在事務(wù)性工作方面給主程序員提供充分支持，所有通信都通過一兩個人進(jìn)行。這種組織方式類似于外科手術(shù)小組的組織主程序員組的兩個重要特性:專業(yè)化：該組每名成員僅完成他們受過專業(yè)訓(xùn)練的那些工作。層次性：主刀大夫指揮每名組員工作，并對手術(shù)全面負(fù)責(zé)。人員組織典型的主程序員組的組織形式如圖，該組由主程序員、后備程序員、編程秘書以及1－3名程序員組成在必要的時候．該組還有其他領(lǐng)域的專家協(xié)助編輯秘書主程序員后備程序員程序員程序員程序員人員組織ChiefProgrammerAssistantCPProgramManagerProgramManagerAdminis-trationLibrarianTestTeamSeniorProgrammerJuniorProgrammer

全面負(fù)責(zé)設(shè)計、編碼、測試和安裝主要負(fù)責(zé)測試，必要時替代CP.負(fù)責(zé)和項目有關(guān)的全部事務(wù)性工作行政、后勤管理文檔、工具管理

提出具體測試方案，編寫Driver和Stub,進(jìn)行測試.后備編程力量主程序員組(ChiefProgrammerTeam)：BakerIBM,1972主程序員組核心人員的分工如下所述：主程序員既是成功的管理人員又是經(jīng)驗豐富、技術(shù)好、能力強(qiáng)的高級程序員，負(fù)責(zé)體系結(jié)構(gòu)設(shè)計和關(guān)鍵部分(或復(fù)雜部分)的詳細(xì)設(shè)計，并且負(fù)責(zé)指導(dǎo)其他程序員完成詳細(xì)設(shè)計和編碼工作。后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗，他協(xié)助主程序員工作并且在必要時(例如，主程序員生病、出差或“跳槽”)接替主程序員的工作。平時，后備程序員的工作主要是，設(shè)計測試方案、分析測試結(jié)果及獨立于設(shè)計過程的其他工作．編程秘書負(fù)責(zé)完成與項目有關(guān)的全部事務(wù)性工作，例如，維護(hù)項目資料庫和項目文檔，編譯、鏈接、執(zhí)行源程序和測試用例。人員組織主程序員制在許多方面卻是不切實際的首先，主程序員應(yīng)該是高級程序員和優(yōu)秀管理者的結(jié)合體。在現(xiàn)實社會中這樣的人才并不多見。其次，后備程序員更難找．人們期望后備程序員像主程序員一樣優(yōu)秀，但是，他們必須坐在“替補(bǔ)席”上，拿著較低的工資等待隨時接替主程序員的工作。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作．第三，編程秘書也很難找到。專業(yè)的軟件技術(shù)人員一般都厭煩日常的事務(wù)性工作，但是，人們卻期望編程秘書整天只干這類工作。人員組織3.現(xiàn)代程序員組“主程序員”應(yīng)該由兩個人共同擔(dān)任一個技術(shù)負(fù)責(zé)人，負(fù)責(zé)小組的技術(shù)活動；技術(shù)組長自然要參與全部代碼審查工作。因為他要對代碼的各方面質(zhì)量負(fù)責(zé)；一個行政負(fù)責(zé)人．負(fù)責(zé)所有非技術(shù)性事務(wù)的管理決策。行政組長不可以參與代碼審查工作，因為他的職責(zé)是對程序員的業(yè)績進(jìn)行評價。行政組長應(yīng)該在常規(guī)調(diào)度會議上了解每名組員的技術(shù)能力和工作業(yè)績。人員組織技術(shù)組長行政組長程序員程序員程序員人員組織在開始工作之前明確劃分技術(shù)組長和行政組長的管理權(quán)限由于程序員組成員人數(shù)不宜過多，當(dāng)軟件項目規(guī)模較大時，應(yīng)該把程序員分成若干個小組，采用圖13.7所示的組織結(jié)構(gòu)。人員組織程序員程序員程序員程序員程序員程序員程序員程序員組長組長組長項目經(jīng)理人員組織把民主制程序員組和主程序員組的優(yōu)點結(jié)合起來的另一種方法。是在合適的地方采用分散做決定的方法，如圖13．8所示，這樣做有利于形成暢通的通信渠道，以便充分發(fā)揮每個程序員的積極性和主動性，集思廣益攻克技術(shù)難關(guān)。這種組織方式對于適合采用民主方法的那類問題(例如，研究性項目或遇到技術(shù)難題需要用集體智慧攻關(guān))非常有效．盡管這種組織方式適當(dāng)?shù)匕l(fā)揚(yáng)了民主，但是上下級之間的箭頭(即管理關(guān)系)仍然是向下的．也就是說，是在集中指導(dǎo)下發(fā)揚(yáng)民主。人員組織程序員程序員程序員程序員程序員程序員程序員程序員組長組長組長項目經(jīng)理人員組織課程內(nèi)容提綱第13章：“軟件項目管理”估算軟件規(guī)模開發(fā)工作量估算進(jìn)度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型軟件質(zhì)量軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的程度”。上述定義強(qiáng)調(diào)了下述的3個要點：(1)軟件需求是度量軟件質(zhì)量的基礎(chǔ)，與需求不一致就是質(zhì)量不高。(2)指定的開發(fā)標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開發(fā)的準(zhǔn)則，如果沒有遵守這些準(zhǔn)則，幾乎肯定會導(dǎo)致軟件質(zhì)量不高。(3)通常，有一組沒有顯式描述的隱含需求(例如，軟件應(yīng)該是容易維護(hù)的)。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質(zhì)量仍然是值得懷疑的。質(zhì)量保證影響軟件質(zhì)量的主要因素這些因素是從管理角度對軟件質(zhì)量的度量分為：產(chǎn)品運(yùn)行，產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。圖13.9描繪了軟件質(zhì)量因素和上述3種傾向(或產(chǎn)品活動)之間的關(guān)系表13.7列出了軟件質(zhì)量因素的簡明定義質(zhì)量保證產(chǎn)品運(yùn)行Operation產(chǎn)品修改Revision產(chǎn)品轉(zhuǎn)移Transition可理解性（我能理解它嗎？）可維修性（我能修復(fù)它嗎？）靈活性（我能改變它嗎？）可測試性（我能測試它嗎？）可移植性（我能在另一臺機(jī)器上使用它嗎？）可再用性（我能再用它的某些部分嗎？）互運(yùn)行性（我能把它和另一個系統(tǒng)結(jié)合嗎？）正確性（它按我的需要工作嗎？）健壯性（對意外環(huán)境它能適當(dāng)?shù)仨憫?yīng)嗎？）效率（完成預(yù)定功能時它需要的資源多嗎？）完整性（它是安全的嗎？）可用性（我能使用它嗎？）風(fēng)險（能按預(yù)定計劃完成它嗎？）軟件質(zhì)量因素與產(chǎn)活動的關(guān)系質(zhì)量保證質(zhì)量保證軟件質(zhì)量保證措施軟件質(zhì)量保證(softwarequalityasssurance，SQA)的措施主要有：基于非執(zhí)行的測試（也稱為復(fù)審或評審）基于執(zhí)行的測試（即以前講過的軟件測試）程序正確性證明質(zhì)量保證軟件質(zhì)量保證措施復(fù)審主要用來保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量；基于執(zhí)行的測試需要在程序編寫出來之后進(jìn)行，它是保證軟件質(zhì)量的最后一道防線；程序正確性證明使用數(shù)學(xué)方法嚴(yán)格驗證程序是否與對它的說明完全一致。質(zhì)量保證參加軟件質(zhì)量保證工作的人員，可以劃分成下述兩類：軟件工程師通過采用先進(jìn)的技術(shù)方法和度量，進(jìn)行正式的技術(shù)復(fù)審以及完成計劃周密的軟件測試來保證軟件質(zhì)量。SQA小組的職責(zé)，是輔助軟件工程師以獲得高質(zhì)量的軟件產(chǎn)品。其從事的軟件質(zhì)量保證活動主要是：計劃，監(jiān)督，記錄，分析和報告。簡而言之．SQA小組的作用是，通過確保軟件過程的質(zhì)量來保證軟件產(chǎn)品的質(zhì)量．質(zhì)量保證課程內(nèi)容提綱第13章：“軟件項目管理”估算軟件規(guī)模開發(fā)工作量估算進(jìn)度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型任何軟件開發(fā)都是迭代過程，在設(shè)計過程會發(fā)現(xiàn)需求說明書中的問題，在實現(xiàn)過程又會暴露出設(shè)計中的錯誤……。隨著時間推移客戶的需求也會或多或少發(fā)生變化，在開發(fā)軟件的過程中，變化(或稱為變動)既是必要的，又是不可避免的。軟件配置管理是在軟件的整個生命期內(nèi)管理變化的一組活動。具體地說，這組活動用來：①標(biāo)識變化；②控制變化；③確保適當(dāng)?shù)貙崿F(xiàn)了變化；④向需要知道這類信息的人報告變化。軟件配置管理軟件配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標(biāo)是使變化更正確且更容易被適應(yīng)，在必須變化時減少所需花費的工作量。軟件配置1．軟件配置項軟件過程的輸出信息可以分為3類:

計算機(jī)程序(源代碼和可執(zhí)行程序);

描述計算機(jī)程序的文檔(供技術(shù)人員或用戶使用)；

數(shù)據(jù)(程序內(nèi)包含的或在程序外的)。我們把它們統(tǒng)稱為軟件配置，而這些項就是軟件配置項。軟件配置管理

把軟件配置管理看作是應(yīng)用于整個軟件過程的軟件質(zhì)量保證活動，是專門用于管理變化的軟件質(zhì)量保證活動。2．基線基線是一個軟件配置管理概念，它有助于我們在不嚴(yán)重妨礙合理變化的前提下來控制變化。IEEE把基線定義為：已經(jīng)通過了正式復(fù)審的規(guī)格說明或中間產(chǎn)品，它可以作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只有通過正式的變化控制過程才能改變它?；€就是通過了正式復(fù)審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現(xiàn)變化，但是，必須應(yīng)用特定的、正式的過程(稱為規(guī)程)來評估、實現(xiàn)和驗證每個變化。軟件配置管理軟件配置管理過程軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它的主要任務(wù)是控制變化，同時也負(fù)責(zé)各個軟件配置項和軟件各種版本的標(biāo)識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告具體來說，軟件配置管理主要有5項任務(wù)：標(biāo)識、版本控制、變化控制、配置審計和報告。軟件配置管理1．標(biāo)識軟件配置中的對象為了控制和管理軟件配置項，必須單獨命名每個配置項，然后用面向?qū)ο蠓椒ńM織它們可以標(biāo)識出兩類對象：基本對象和聚集對象(可以把聚集對象作為代表軟件配置完整版本的一種機(jī)制)。基本對象是軟件工程師在分析、設(shè)計、編碼或測試過程中創(chuàng)建出來的“文本單元”，例如，需求規(guī)格說明的一個段落、一個模塊的源程序清單或—組測試用例。聚集對象是基本對象和其他聚集對象的集合。每個對象都有一組能惟一地標(biāo)識它的特征：名字、描述、資源表和“實現(xiàn)”。對象名是無二義性地標(biāo)識該對象的一個字符串。軟件配置管理演化圖軟件配置管理2．版本控制版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術(shù)，用戶能夠通過選擇適當(dāng)?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。實現(xiàn)這個目標(biāo)的方法是，把屬性和軟件的每個版本關(guān)聯(lián)起來，然后通過描述一組所期望的屬性來指定和構(gòu)造所需要的配置。“屬性”，既可以簡單到僅是賦給每個配置對象的具體版本號，也可以復(fù)雜到是一個布爾變量串，其指明了施加到系統(tǒng)上的功能變化的具體類型。軟件配置管理版本和變體軟件配置管理3．變化控制典型的變化控制過程如下：首先評估該變化在技術(shù)方面的得失、可能產(chǎn)生的副作用、對其他配置對象和系統(tǒng)功能的整體影響以及估算出的修改成本。評估的結(jié)果形成“變化報告”，該報告供“變化控制審批者”審閱。對變化的狀態(tài)和優(yōu)先級做最終決策。把要修改的對象從項目數(shù)據(jù)庫中“提取(checkout)”出來，進(jìn)行修改并應(yīng)用適當(dāng)?shù)腟QA活動。把修改后的對象“提交(checkin)”進(jìn)數(shù)據(jù)庫．并用適當(dāng)?shù)陌姹究刂茩C(jī)制創(chuàng)建該軟件的下一個版本。軟件配置管理在一個軟件配置項變成基線之前，僅需應(yīng)用非正式的變化控制。該配置對象的開發(fā)者可以對它進(jìn)行任何合理的修改(只要修改不會影響到開發(fā)者工作范圍之外的系統(tǒng)需求)。一旦該對象經(jīng)過了正式技術(shù)復(fù)審并獲得批準(zhǔn)，就創(chuàng)建了一個基線．而一旦一個軟件配置項變成了基線．就開始實施項目級的變化控制。為了進(jìn)行修改開發(fā)者必須獲得項目管理者的批準(zhǔn)(如果變化是“局部的”)，如果變化影響到其他軟件配置項，還必須得到變化控制審批者的批準(zhǔn)。在某些情況下，可以省略正式的變化請求、變化報告和工程變化命令，但是，必須評估每個變化并且跟蹤和復(fù)審所有變化。軟件配置管理訪問和同步控制軟件配置管理4．配置審計為了確保適當(dāng)?shù)貙崿F(xiàn)了所需要的變化，通常從下述兩方面采取措施：①正式的技術(shù)復(fù)審；②軟件配置審計。正式的技術(shù)復(fù)審關(guān)注被修改后的配置對象的技術(shù)正確性。復(fù)審者審查該對象以確定它與其他軟件配置項的一致性，并檢查是否有遺漏或副作用．軟件配置審計通過評估配置對象的那些通常不在復(fù)審過程中考慮的特征(例如，修改時是否遵循了軟件工程標(biāo)準(zhǔn)，是否在該配置項中顯著地標(biāo)明了所做的修改，是否注明了修改日期和修改者，是否適當(dāng)?shù)馗铝怂邢嚓P(guān)的軟件配置項，是否遵循了標(biāo)注變化、記錄變化和報告變化的規(guī)程)，而成為對正式技術(shù)復(fù)審的補(bǔ)充。軟件配置管理5．狀態(tài)報告配置狀態(tài)報告回答下述問題：①發(fā)生了什么事?②誰做的這件事?③這件事是什么時候發(fā)生的?④它將影響哪些其他事物?

配置狀態(tài)變化對大型軟件開發(fā)項目的成功有重大影響。當(dāng)大量人員在一起工作時，可能一個人并不知道另一個人在做什么。兩名開發(fā)人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾個人月的工作量根據(jù)過時的硬件規(guī)格說明開發(fā)軟件，察覺到所建議的修改有嚴(yán)重副作用的人可能還不知道該項修改正在進(jìn)行。配置狀態(tài)報告通過改善所有相關(guān)人員之間的通信，幫助消除這些問題。軟件配置管理課程內(nèi)容提綱第13章：“軟件項目管理”估算軟件規(guī)模開發(fā)工作量估算進(jìn)度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型能力成熟度模型(capabilitymaturitymodel，CMM)美國卡內(nèi)基梅隆大學(xué)軟件工程研究所在美國國防部資助下于20世紀(jì)80年代末建立的用于評價軟件機(jī)構(gòu)的軟件過程能力成熟度的模型。最初，建立此模型的目的主要是，為大型軟件項目的招投標(biāo)活動提供一種全面而客觀的評審依據(jù)，后來此模型又同時被應(yīng)用于許多軟件機(jī)構(gòu)內(nèi)部的過程改進(jìn)活動中。能力成熟度模型，CMM能力成熟度模型的基本思想是由于問題是由我們管理軟件過程的方法不當(dāng)引起的，所以新軟件技術(shù)的運(yùn)用并不會自動提高軟件的生產(chǎn)率和質(zhì)量。能力成熟度模型有助于軟件開發(fā)機(jī)構(gòu)建立一個有規(guī)律的、成熟的軟件過程。改進(jìn)后的軟件過程將開發(fā)出質(zhì)量更好的軟件，使更多的軟件項目免受時間和費用超支之苦。軟件過程包括各種活動、技術(shù)和工具，它實際上既包括了軟件開發(fā)的技術(shù)方面又包括了管理方面。CMM的策略是，力圖改進(jìn)對軟件過程的管理，而在技術(shù)方面的改進(jìn)是其必然的結(jié)果。能力成熟度模型，CMMCMM在改進(jìn)軟件過程中所起的作用指導(dǎo)軟件機(jī)構(gòu)通過確定當(dāng)前的過程成熟度并識別出對過程改進(jìn)起關(guān)鍵作用的問題，從而明確過程改進(jìn)的方向和策略。通過集中開展與過程改進(jìn)的方向和策略相一致的一組過程改進(jìn)活動，軟件機(jī)構(gòu)便能穩(wěn)步而有效地改進(jìn)其軟件過程，使其軟件過程能力得到循序漸進(jìn)的提高。CMM把軟件過程從無序到有序的進(jìn)化過程分成5個階段，并把這些階段排序，形成5個逐層提高的等級。這5個成熟度等級定義了一個有序的尺度，用以測量軟件機(jī)構(gòu)的軟件過程成熟度和評價其軟件過程能力，這些等級還能幫助軟件機(jī)構(gòu)把應(yīng)做的改進(jìn)工作排出優(yōu)先次序。成熟度等級是妥善定義的向成熟軟件機(jī)構(gòu)前進(jìn)途中的平臺，每個成熟度等級都為軟件過程的繼續(xù)改進(jìn)提供了一個臺階。能力成熟度模型，CMMCMM從“1級”到“5級”，反映出一個軟件機(jī)構(gòu)為了達(dá)到從一個無序的、混亂的軟件過程進(jìn)化到一種有序的、有紀(jì)律的且成熟的軟件過程的目的，必須經(jīng)歷的過程改進(jìn)活動的途徑。每一個成熟度級別都是該軟件機(jī)構(gòu)沿著改進(jìn)其過程的途徑前進(jìn)途中的一個臺階，后一個成熟度級別是前一個級別的軟件過程的進(jìn)化目標(biāo)。CMM的每個成熟度級別中都包含一組過程改進(jìn)的目標(biāo)，滿足這些目標(biāo)后一個機(jī)構(gòu)的軟件過程就從當(dāng)前級別進(jìn)化到下一個成熟度級別，每達(dá)到成熟度級別框架的下一個級別，該機(jī)構(gòu)的軟件過程都得到一定程度的完善和優(yōu)化，也使得過程能力得到提高；隨著成熟度級別不斷提高，該機(jī)構(gòu)的過程改進(jìn)活動取得了更加顯著的成效，從而使軟件過程得到進(jìn)一步的完善和優(yōu)化。能力成熟度模型，CMMCMM通過定義能力成熟度的5個等級，引導(dǎo)軟件開發(fā)機(jī)構(gòu)不斷識別出其軟件過程的缺陷，井指出應(yīng)該做哪些改進(jìn)，但是，它并不提供做這些改進(jìn)的具體措施。能力成熟度的5個等級從低到高依次是初始級(又稱為1級)，可重復(fù)級（又稱為2級）已定義級(又稱為3級)，已管理級(又稱為4級)優(yōu)化級(又稱為5級)。能力成熟度模型，CMM1．初始級軟件過程的特征是無序的，有時甚至是混亂的。幾乎沒有什么過程是經(jīng)過定義的(即沒有一個定型的過程模型)，項目能否成功完全取決于開發(fā)人員的個人能力．處于這個最低成熟度等級的軟件機(jī)構(gòu)，基本上沒有健全的軟件工程管理制度，其軟件過程完全取決于項目組的人員配備．所以具有不可預(yù)測性，人員變了過程也隨之改變，由于缺乏健全的管理和周密的計劃，延期交付和費用超支的情況經(jīng)常發(fā)生，結(jié)果，