軟件工程學(xué)-軟件項目管理

第13章軟件項目管理13.1估算軟件規(guī)模13.2工作量估算13.3進度計劃13.4人員組織13.5質(zhì)量保證13.6軟件配置管理13.7能力成熟度模型13.8小結(jié)習題在經(jīng)歷了若干個大型軟件工程項目的失敗之后，人們才逐漸認識到軟件項目管理的重要性和特殊性。事實上，這些項目的失敗并不是由于從事軟件開發(fā)工作的軟件工程師無能，正相反，他們之中的絕大多數(shù)是當時杰出的技術(shù)專家。這些工程項目的失敗主要是因為管理不善。所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。軟件項目管理先于任何技術(shù)活動之前開始，并且貫穿于軟件的整個生命周期之中。軟件項目管理過程從一組項目計劃活動開始，而制定計劃的基礎(chǔ)是工作量估算和完成期限估算。為了估算項目的工作量和完成期限，首先需要估算軟件的規(guī)模。代碼行技術(shù)是比較簡單的定量估算軟件規(guī)模的方法。這種方法依據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷史數(shù)據(jù)，估計實現(xiàn)一個功能所需要的源程序行數(shù)。當有以往開發(fā)類似產(chǎn)品的歷史數(shù)據(jù)可供參考時，用這種方法估計出的數(shù)值還是比較準確的。把實現(xiàn)每個功能所需要的源程序行數(shù)累加起來，就可得到實現(xiàn)整個軟件所需要的源程序行數(shù)。13.1估算軟件規(guī)模

13.1.1代碼行技術(shù)為了使得對程序規(guī)模的估計值更接近實際值，可以由多名有經(jīng)驗的軟件工程師分別做出估計。每個人都估計程序的最小規(guī)模(a)、最大規(guī)模(b)和最可能的規(guī)模(m)，分別算出這3種規(guī)模的平均值,和之后，再用下式計算程序規(guī)模的估計值： L= (13.1)用代碼行技術(shù)估算軟件規(guī)模時，當程序較小時常用的單位是代碼行數(shù)（LOC），當程序較大時常用的單位是千行代碼數(shù)（KLOC）。代碼行技術(shù)的主要優(yōu)點是，代碼是所有軟件開發(fā)項目都有的“產(chǎn)品”，而且很容易計算代碼行數(shù)。代碼行技術(shù)的缺點是：源程序僅是軟件配置的一個成分，用它的規(guī)模代表整個軟件的規(guī)模似乎不太合理；用不同語言實現(xiàn)同一個軟件所需要的代碼行數(shù)并不相同；這種方法不適用于非過程語言。為了克服代碼行技術(shù)的缺點，人們又提出了功能點技術(shù)。功能點技術(shù)依據(jù)對軟件信息域特性和軟件復(fù)雜性的評估結(jié)果，估算軟件規(guī)模。這種方法用功能點（FP）為單位度量軟件規(guī)模。1.信息域特性功能點技術(shù)定義了信息域的5個特性，分別是輸入項數(shù)(Inp)、輸出項數(shù)(Out)、查詢數(shù)(Inq)、主文件數(shù)(Maf)和外部接口數(shù)(Inf)。下面講述這5個特性的含義。13.1.2功能點技術(shù)（1）輸入項數(shù)：用戶向軟件輸入的項數(shù)，這些輸入給軟件提供面向應(yīng)用的數(shù)據(jù)。輸入不同于查詢，后者單獨計數(shù)，不計入輸入項數(shù)中。（2）輸出項數(shù)：軟件向用戶輸出的項數(shù)，它們向用戶提供面向應(yīng)用的信息，例如，報表和出錯信息等。報表內(nèi)的數(shù)據(jù)項不單獨計數(shù)。（3）查詢數(shù)：查詢即是一次聯(lián)機輸入，它導(dǎo)致軟件以聯(lián)機輸出方式產(chǎn)生某種即時響應(yīng)。（4）主文件數(shù)：邏輯主文件（即數(shù)據(jù)的一個邏輯組合，它可能是大型數(shù)據(jù)庫的一部分或是一個獨立的文件）的數(shù)目。（5）外部接口數(shù)：機器可讀的全部接口（例如，磁盤或磁帶上的數(shù)據(jù)文件）的數(shù)量，用這些接口把信息傳送給另一個系統(tǒng)。2.估算功能點的步驟用下述3個步驟，可估算出一個軟件的功能點數(shù)（即軟件規(guī)模）。（1）計算未調(diào)整的功能點數(shù)UFP首先，把產(chǎn)品信息域的每個特性(即Inp、Out、Inq、Maf和Inf)都分類為簡單級、平均級或復(fù)雜級，并根據(jù)其等級為每個特性分配一個功能點數(shù)（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個復(fù)雜級的輸入項分配6個功能點）。然后，用下式計算未調(diào)整的功能點數(shù)UFP：UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中，ai(1≤i≤5)是信息域特性系數(shù)，其值由相應(yīng)特性的復(fù)雜級別決定，如表13.1（見書297頁）所示。(2)計算技術(shù)復(fù)雜性因子TCF這一步驟度量14種技術(shù)因素對軟件規(guī)模的影響程度。這些因素包括高處理率、性能標準（例如，響應(yīng)時間）、聯(lián)機更新等，在表13.2（見書297頁）中列出了全部技術(shù)因素，并用Fi(1≤i≤14)代表這些因素。根據(jù)軟件的特點，為每個因素分配一個從0（不存在或?qū)浖?guī)模無影響）到5（有很大影響）的值。然后，用下式計算技術(shù)因素對軟件規(guī)模的綜合影響程度DI：

DI=技術(shù)復(fù)雜性因子TCF由下式計算：TCF=0.65+0.01×DI因為DI的值在0~70之間，所以TCF的值在0.65~1.35之間。（3）計算功能點數(shù)FP用下式計算功能點數(shù)FP：FP=UFP×TCF功能點數(shù)與所用的編程語言無關(guān)，看起來功能點技術(shù)比代碼行技術(shù)更合理一些。但是，在判斷信息域特性復(fù)雜級別和技術(shù)因素的影響程度時，存在著相當大的主觀因素。軟件估算模型使用由經(jīng)驗導(dǎo)出的公式來預(yù)測軟件開發(fā)工作量，工作量是軟件規(guī)模（KLOC或FP）的函數(shù)，工作量的單位通常是人月（pm)。支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個項目的樣本集中總結(jié)出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開發(fā)環(huán)境。13.2工作量估算這類模型的總體結(jié)構(gòu)形式如下：E=A+B×(ev)C其中，A、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)Bailey_Basili模型E=5.5+0.73×(KLOC)1.1613.2.1靜態(tài)單變量模型(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.12FP從上面列出的模型可以看出，對于相同的KLOC或FP值，用不同模型估算將得出不同的結(jié)果。主要原因是，這些模型多數(shù)都是僅根據(jù)若干應(yīng)用領(lǐng)域中有限個項目的經(jīng)驗數(shù)據(jù)推導(dǎo)出來的，適用范圍有限。因此，必須根據(jù)當前項目的特點選擇適用的估算模型，并且根據(jù)需要適當?shù)卣{(diào)整（例如，修改模型常數(shù)）估算模型。動態(tài)多變量模型也稱為軟件方程式，它是根據(jù)從4000多個當代軟件項目中收集的生產(chǎn)率數(shù)據(jù)推導(dǎo)出來的。該模型把工作量看作是軟件規(guī)模和開發(fā)時間這兩個變量的函數(shù)。動態(tài)多變量估算模型的形式如下：E=(LOC×B0.333/P)3×(1/t)4 (13.2)其中，E是以人月或人年為單位的工作量；t是以月或年為單位的項目持續(xù)時間；13.2.2動態(tài)多變量模型B是特殊技術(shù)因子，它隨著對測試、質(zhì)量保證、文檔及管理技術(shù)的需求的增加而緩慢增加，對于較小的程序（KLOC=5~15），B=0.16,對于超過70KLOC的程序，B=0.39;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?？梢詮臍v史數(shù)據(jù)導(dǎo)出適用于當前項目的生產(chǎn)率參數(shù)值。從（13.2）式可以看出，開發(fā)同一個軟件（即LOC固定）的時候，如果把項目持續(xù)時間延長一些，則可降低完成項目所需的工作量。COCOMO是構(gòu)造性成本模型（constructivecostmodel)的英文縮寫。1981年Boehm在《軟件工程經(jīng)濟學(xué)》中首次提出了COCOMO模型，本書第三版曾對此模型作了介紹。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經(jīng)驗。13.2.3COCOMO2模型COCOMO2給出了3個層次的軟件開發(fā)工作量估算模型，這3個層次的模型在估算工作量時，對軟件細節(jié)考慮的詳盡程度逐級增加。這些模型既可以用于不同類型的項目，也可以用于同一個項目的不同開發(fā)階段。這3個層次的估算模型分別是：（1）應(yīng)用系統(tǒng)組成模型。這個模型主要用于估算構(gòu)建原型的工作量，模型名字暗示在構(gòu)建原型時大量使用已有的構(gòu)件。（2）早期設(shè)計模型。這個模型適用于體系結(jié)構(gòu)設(shè)計階段。（3）后體系結(jié)構(gòu)模型。這個模型適用于完成體系結(jié)構(gòu)設(shè)計之后的軟件開發(fā)階段。下面以后體系結(jié)構(gòu)模型為例，介紹COCOMO2模型。該模型把軟件開發(fā)工作量表示成代碼行數(shù)（KLOC）的非線性函數(shù)：

E=

(13.3)其中，E是開發(fā)工作量（以人月為單位），a是模型系數(shù)，KLOC是估計的源代碼行數(shù)（以千行為單位），b是模型指數(shù)，fi(i=1~17)是成本因素。每個成本因素都根據(jù)它的重要程度和對工作量影響大小被賦予一定數(shù)值（稱為工作量系數(shù)）。這些成本因素對任何一個項目的開發(fā)工作量都有影響，即使不使用COCOMO2模型估算工作量，也應(yīng)該重視這些因素。Boehm把成本因素劃分成產(chǎn)品因素、平臺因素、人員因素和項目因素等4類。表13.3（見書300頁）列出了COCOMO2模型使用的成本因素及與之相聯(lián)系的工作量系數(shù)。與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化，這些變化反映了在過去十幾年中軟件行業(yè)取得的巨大進步。（1）新增加了4個成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續(xù)性（即人員穩(wěn)定程度）和多地點開發(fā)。這個變化表明，這些因素對開發(fā)成本的影響日益增加。（2）略去了原始模型中的2個成本因素（計算機切換時間和使用現(xiàn)代程序設(shè)計實踐）?，F(xiàn)在，開發(fā)人員普遍使用工作站開發(fā)軟件，批處理的切換時間已經(jīng)不再是問題。而“現(xiàn)代程序設(shè)計實踐”已經(jīng)發(fā)展成內(nèi)容更廣泛的“成熟的軟件工程實踐”的概念，并且在COCOMO2工作量方程的指數(shù)b中考慮了這個因素的影響。（3）某些成本因素（分析員能力、平臺經(jīng)驗、語言和工具經(jīng)驗）對生產(chǎn)率的影響（即工作量系數(shù)最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了。為了確定工作量方程中模型指數(shù)b的值，原始的COCOMO模型把軟件開發(fā)項目劃分成組織式、半獨立式和嵌入式這樣3種類型，并指定每種項目類型所對應(yīng)的b值（分別是1.05，1.12和1.20）。COCOMO2采用了更加精細得多的b分級模型，這個模型使用5個分級因素Wi(1≤i≤5),其中每個因素都劃分成從甚低（Wi=5)到特高（Wi=0)的6個級別，然后用下式計算b的數(shù)值：b= (13.4)因此，b的取值范圍為1.01~1.26。顯然，這種分級模式比原始COCOMO模型的分級模式更精細、更靈活。COCOMO2使用的5個分級因素如下所述：（1）項目先例性。這個分級因素指出，對于開發(fā)組織來說該項目的新奇程度。諸如開發(fā)類似系統(tǒng)的經(jīng)驗，需要創(chuàng)新體系結(jié)構(gòu)和算法，以及需要并行開發(fā)硬件和軟件等因素的影響，都體現(xiàn)在這個分級因素中。（2）開發(fā)靈活性。這個分級因素反映出，為了實現(xiàn)預(yù)先確定的外部接口需求及為了及早開發(fā)出產(chǎn)品而需要增加的工作量。（3）風險排除度。這個分級因素反映了重大風險已被消除的比例。在多數(shù)情況下，這個比例和指定了重要模塊接口（即選定了體系結(jié)構(gòu)）的比例密切相關(guān)。（4）項目組凝聚力。這個分級因素表明了開發(fā)人員相互協(xié)作時可能存在的困難。這個因素反映了開發(fā)人員在目標和文化背景等方面相一致的程度，以及開發(fā)人員組成一個小組工作的經(jīng)驗。（5）過程成熟度。這個分級因素反映了按照能力成熟度模型（見13.7節(jié)）度量出的項目組織的過程成熟度。在原始的COCOMO模型中，僅粗略地考慮了前兩個分級因素對指數(shù)b之值的影響。工作量方程中模型系數(shù)a的典型值為3.0，在實際工作中應(yīng)該根據(jù)歷史經(jīng)驗數(shù)據(jù)確定一個適合本組織當前開發(fā)的項目類型的數(shù)值。不論從事哪種技術(shù)性項目，實際情況都是，在實現(xiàn)一個大目標之前往往必須完成數(shù)以百計的小任務(wù)（也稱為作業(yè)）。這些任務(wù)中有一些是處于“關(guān)鍵路徑”（見13.3.5節(jié)）之外的，其完成時間如果沒有嚴重拖后，就不會影響整個項目的完成時間；其他任務(wù)則處于關(guān)鍵路徑之中，如果這些“關(guān)鍵任務(wù)”的進度拖后，則整個項目的完成日期就會拖后，管理人員應(yīng)該高度關(guān)注關(guān)鍵任務(wù)的進展情況。13.3進度計劃沒有一個普遍適用于所有軟件項目的任務(wù)集合，因此，一個有效的軟件過程應(yīng)該定義一個適用于當前項目的任務(wù)集合。一個任務(wù)集合包括一組軟件工程工作任務(wù)、里程碑和可交付的產(chǎn)品。為一個項目所定義的任務(wù)集合，必須包括為獲得高質(zhì)量的軟件產(chǎn)品而應(yīng)該完成的所有任務(wù)，但是同時又不能讓項目組承擔不必要的工作。項目管理者的目標是定義全部項目任務(wù)，識別出關(guān)鍵任務(wù)，跟蹤關(guān)鍵任務(wù)的進展狀況，以保證能及時發(fā)現(xiàn)拖延進度的情況。為達到上述目標，管理者必須制定一個足夠詳細的進度表，以便監(jiān)督項目進度并控制整個項目。軟件項目的進度安排是這樣一種活動，它通過把工作量分配給特定的軟件工程任務(wù)并規(guī)定完成各項任務(wù)的起止日期，從而將估算出的項目工作量分布于計劃好的項目持續(xù)期內(nèi)。進度計劃將隨著時間的流逝而不斷演化。在項目計劃的早期，首先制定一個宏觀的進度安排表，標識出主要的軟件工程活動和這些活動影響到的產(chǎn)品功能。隨著項目的進展，把宏觀進度表中的每個條目都精化成一個詳細進度表，從而標識出完成一個活動所必須實現(xiàn)的一組特定任務(wù)，并安排好了實現(xiàn)這些任務(wù)的進度。估算出完成給定項目所需的總工作量之后，接下來需要回答的問題就是：用多長時間才能完成該項目的開發(fā)工作？對于一個估計工作量為20人月的項目，可能想出下列幾種進度表：1個人用20個月完成該項目；4個人用5個月完成該項目；20個人用1個月完成該項目。但是，這些進度表并不現(xiàn)實，實際上軟件開發(fā)時間與從事開發(fā)工作的人數(shù)之間并不是簡單的反比關(guān)系。13.3.1估算開發(fā)時間通常，成本估算模型也同時提供了估算開發(fā)時間T的方程。與工作量方程不同，各種模型估算開發(fā)時間的方程很相似，例如：(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是開發(fā)工作量（以人月為單位），T是開發(fā)時間（以月為單位）。用上列方程計算出的T值，代表正常情況下的開發(fā)時間。客戶往往希望縮短軟件開發(fā)時間，顯然，為了縮短開發(fā)時間應(yīng)該增加從事開發(fā)工作的人數(shù)。但是，經(jīng)驗告訴我們，隨著開發(fā)小組規(guī)模擴大，個人生產(chǎn)率將下降，以致開發(fā)時間與從事開發(fā)工作的人數(shù)并不成反比關(guān)系。出現(xiàn)這種現(xiàn)象主要有下述兩個原因：當小組變得更大時，每個人需要用更多時間與組內(nèi)其他成員討論問題、協(xié)調(diào)工作，因此增加了通信開銷。如果在開發(fā)過程中增加小組人員，則最初一段時間內(nèi)項目組總生產(chǎn)率不僅不會提高反而會下降。這是因為新成員在開始時不僅不是生產(chǎn)力，而且在他們學(xué)習期間還需要花費小組其他成員的時間。綜合上述兩個原因，存在被稱為Brooks規(guī)律的下述現(xiàn)象：向一個已經(jīng)延期的項目增加人力，只會使得它更加延期。下面讓我們研究項目組規(guī)模與項目組總生產(chǎn)率的關(guān)系。項目組成員之間的通信路徑數(shù)，由項目組人數(shù)和項目組結(jié)構(gòu)決定。如果項目組共有P名組員，每個組員必須與所有其他組員通信以協(xié)調(diào)開發(fā)活動，則通信路徑數(shù)為P(P-1)/2。如果每個組員只需與另外一個組員通信，則通信路徑數(shù)為P-1。通信路徑數(shù)少于P-1是不合理的，因為那將導(dǎo)致出現(xiàn)與任何人都沒有聯(lián)系的組員。因此，通信路徑數(shù)大約在P~P2/2的范圍內(nèi)變化。也就是說，在一個層次結(jié)構(gòu)的項目組中，通信路徑數(shù)為Pα，其中1<α<2。對于某一個組員來說，他與其他組員通信的路徑數(shù)在1~（P-1）的范圍內(nèi)變化。如果不與任何人通信時個人生產(chǎn)率為L，而且每條通信路徑導(dǎo)致生產(chǎn)率減少l，則組員個人平均生產(chǎn)率為Lr=L-l(P-1)r (13.5)其中，r是對通信路徑數(shù)的度量，0<r≤1(假設(shè)至少有一名組員需要與一個以上的其他組員通信，因此r>0)。對于一個規(guī)模為P的項目組，從（13.5）式導(dǎo)出項目組的總生產(chǎn)率為Ltot=P(L-l(P-1)r) (13.6)對于給定的一組L，l和r的值，總生產(chǎn)率Ltot是項目組規(guī)模P的函數(shù)。隨著P值增加，Ltot將從0增大到某個最大值，然后再下降。因此，存在一個最佳的項目組規(guī)模Popt，這個規(guī)模的項目組其總生產(chǎn)率最高。讓我們舉例說明項目組規(guī)模與生產(chǎn)率的關(guān)系。假設(shè)個人最高生產(chǎn)率為500LOC/月（即L=500），每條通信路徑導(dǎo)致生產(chǎn)率下降10%（即l=50)。如果每個組員都必須與組內(nèi)所有其他組員通信（r=1)，則項目組規(guī)模與生產(chǎn)率的關(guān)系列在表13.4（見書304頁）中，可見，在這種情況下項目組的最佳規(guī)模是5.5人，即Popt=5.5。事實上，做任何事情都需要時間，我們不可能用“人力換時間”的辦法無限縮短一個軟件的開發(fā)時間。Boehm根據(jù)經(jīng)驗指出，軟件項目的開發(fā)時間最多可以減少到正常開發(fā)時間的75%。如果要求一個軟件系統(tǒng)的開發(fā)時間過短，則開發(fā)成功的概率幾乎為零。Gantt（甘特）圖是歷史悠久、應(yīng)用廣泛的制定進度計劃的工具，下面通過一個非常簡單的例子介紹這種工具。假設(shè)有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步完成：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設(shè)一共分配了15名工人去完成這項工作，然而工具卻很有限：只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢?13.3.2Gantt圖一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法，因為總共有15名工人，然而每種工具卻只有5件，這樣安排工作在任何時候都有10名工人閑著沒活干。讀者可能已經(jīng)想到，應(yīng)該采用“流水作業(yè)法”，也就是說，首先由5名工人用刮板刮掉第1面墻上的舊漆(這時其余10名工人休息)，當?shù)?面墻刮凈后，另外5名工人立即用刷子給這面墻刷新漆(與此同時拿刮板的5名工人轉(zhuǎn)去刮第2面墻上的舊漆)，一旦刮舊漆的工人轉(zhuǎn)到第3面墻而且刷新漆的工人轉(zhuǎn)到第2面墻以后，余下的5名工人立即拿起刮刀去清除濺在第1面墻窗戶上的油漆，……。這樣安排每個工人都有活干，因此能夠在較短的時間內(nèi)完成任務(wù)。假設(shè)木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍，此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊漆，清理(即清除濺在窗戶上的油漆)需要的時間最少。表13.5（見書305頁）列出了估計每道工序需要用的時間?？梢允褂脠D13.1中的Gantt圖描繪上述流水作業(yè)過程：在時間為零時開始刮第1面墻上的舊漆，兩小時后刮舊漆的工人轉(zhuǎn)去刮第2面墻，同時另5名工人開始給第1面墻刷新漆，每當給一面墻刷完新漆之后，第3組的5名工人立即清除濺在這面墻窗戶上的漆。從圖13.1可以看出12小時后刮完所有舊漆，20小時后完成所有墻壁的刷漆工作，再過2小時后清理工作結(jié)束。因此全部工程在22小時后結(jié)束，如果用前述的第一種做法，則需要36小時。圖13.1舊木板房刷漆工程的Gantt圖上一小節(jié)介紹的Gantt圖能很形象地描繪任務(wù)分解情況，以及每個子任務(wù)(作業(yè))的開始時間和結(jié)束時間，因此是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優(yōu)點，但是Gantt圖也有3個主要缺點：(1)不能顯式地描繪各項作業(yè)彼此間的依賴關(guān)系；(2)進度計劃的關(guān)鍵部分不明確，難于判定哪些部分應(yīng)當是主攻和主控的對象；(3)計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。13.3.3工程網(wǎng)絡(luò)當把一個工程項目分解成許多子任務(wù)，并且它們彼此間的依賴關(guān)系又比較復(fù)雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節(jié)省資源又保證進度的計劃，而且還容易發(fā)生差錯。工程網(wǎng)絡(luò)是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務(wù)分解情況以及每項作業(yè)的開始時間和結(jié)束時間，此外，它還顯式地描繪各個作業(yè)彼此間的依賴關(guān)系。因此，工程網(wǎng)絡(luò)是系統(tǒng)分析和系統(tǒng)設(shè)計的強有力的工具。在工程網(wǎng)絡(luò)中用箭頭表示作業(yè)(例如，刮舊漆，刷新漆，清理等)，用圓圈表示事件(一項作業(yè)開始或結(jié)束)。注意，事件僅僅是可以明確定義的時間點，它并不消耗時間和資源。作業(yè)通常既消耗資源又需要持續(xù)一定時間。圖13.2是舊木板房刷漆工程的工程網(wǎng)絡(luò)。圖中表示刮第1面墻上舊漆的作業(yè)開始于事件1，結(jié)束于事件2。用開始事件和結(jié)束事件的編號標識一個作業(yè)，因此“刮第1面墻上舊漆”是作業(yè)1—2。圖13.2舊木板房刷漆工程的工程網(wǎng)絡(luò)在工程網(wǎng)絡(luò)中的一個事件，如果既有箭頭進入又有箭頭離開，則它既是某些作業(yè)的結(jié)束又是另一些作業(yè)的開始。例如，圖13.2中事件2既是作業(yè)1—2(刮第1面墻上的舊漆)的結(jié)束，又是作業(yè)2—3(刮第2面墻上舊漆)和作業(yè)2—4(給第1面墻刷新漆)的開始。也就是說，只有第1面墻上的舊漆刮完之后，才能開始刮第2面墻上舊漆和給第1面墻刷新漆這兩個作業(yè)。因此，工程網(wǎng)絡(luò)顯式地表示了作業(yè)之間的依賴關(guān)系。在圖13.2中還有一些虛線箭頭，它們表示虛擬作業(yè)，也就是事實上并不存在的作業(yè)。引入虛擬作業(yè)是為了顯式地表示作業(yè)之間的依賴關(guān)系。例如，事件4既是給第1面墻刷新漆結(jié)束，又是給第2面墻刷新漆開始(作業(yè)4—6)。但是，在開始給第2面墻刷新漆之前，不僅必須已經(jīng)給第1面墻刷完了新漆，而且第2面墻上的舊漆也必須已經(jīng)刮凈(事件3)。也就是說，在事件3和事件4之間有依賴關(guān)系，或者說在作業(yè)2—3(刮第2面墻上舊漆)和作業(yè)4—6(給第2面墻刷新漆)之間有依賴關(guān)系，虛擬作業(yè)3—4明確地表示了這種依賴關(guān)系。注意，虛擬作業(yè)既不消耗資源也不需要時間。畫出類似圖13.2那樣的工程網(wǎng)絡(luò)之后，系統(tǒng)分析員就可以借助它的幫助估算工程進度了。為此需要在工程網(wǎng)絡(luò)上增加一些必要的信息。首先，把每個作業(yè)估計需要使用的時間寫在表示該項作業(yè)的箭頭上方。注意，箭頭長度和它代表的作業(yè)持續(xù)時間沒有關(guān)系，箭頭僅表示依賴關(guān)系，它上方的數(shù)字才表示作業(yè)的持續(xù)時間。13.3.4估算工程進度其次，為每個事件計算下述兩個統(tǒng)計數(shù)字：最早時刻EET和最遲時刻LET。這兩個數(shù)字將分別寫在表示事件的圓圈的右上角和右下角，如圖13.3左下角的符號所示。事件的最早時刻是該事件可以發(fā)生的最早時間。通常工程網(wǎng)絡(luò)中第一個事件的最早時刻定義為零，其他事件的最早時刻在工程網(wǎng)絡(luò)上從左至右按事件發(fā)生順序計算。計算最早時刻EET使用下述3條簡單規(guī)則：圖13.3舊木板房刷漆工程的完整的工程網(wǎng)絡(luò)(1)考慮進入該事件的所有作業(yè)；(2)對于每個作業(yè)都計算它的持續(xù)時間與起始事件的EET之和；(3)選取上述和數(shù)中的最大值作為該事件的最早時刻EET。按照這種方法，不難沿著工程網(wǎng)絡(luò)從左至右順序算出每個事件的最早時刻，計算結(jié)果標在圖13.3的工程網(wǎng)絡(luò)中(每個圓圈內(nèi)右上角的數(shù)字)。事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發(fā)生的時刻。按慣例，最后一個事件(工程結(jié)束)的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網(wǎng)絡(luò)上從右至左按逆作業(yè)流的方向計算。計算最遲時刻LET使用下述3條規(guī)則：(1)考慮離開該事件的所有作業(yè)；(2)從每個作業(yè)的結(jié)束事件的最遲時刻中減去該作業(yè)的持續(xù)時間；(3)選取上述差數(shù)中的最小值作為該事件的最遲時刻LET。圖13.3中每個圓圈內(nèi)右下角的數(shù)字就是該事件的最遲時刻。圖13.3中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關(guān)鍵路徑，在圖中關(guān)鍵路徑用粗線箭頭表示。關(guān)鍵路徑上的事件(關(guān)鍵事件)必須準時發(fā)生，組成關(guān)鍵路徑的作業(yè)(關(guān)鍵作業(yè))的實際持續(xù)時間不能超過估計的持續(xù)時間，否則工程就不能準時結(jié)束。工程項目的管理人員應(yīng)該密切注視關(guān)鍵作業(yè)的進展情況，如果關(guān)鍵事件出現(xiàn)的時間比預(yù)計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關(guān)鍵作業(yè)中增加資源才會有效果。13.3.5關(guān)鍵路徑不在關(guān)鍵路徑上的作業(yè)有一定程度的機動余地——實際開始時間可以比預(yù)定時間晚一些，或者實際持續(xù)時間可以比預(yù)定的持續(xù)時間長一些，而并不影響工程的結(jié)束時間。一個作業(yè)可以有的全部機動時間等于它的結(jié)束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業(yè)的持續(xù)時間：機動時間=(LET)結(jié)束-(EET)開始-持續(xù)時間對于前述油漆舊木板房的例子，計算得到的非關(guān)鍵作業(yè)的機動時間列在表13.6（見書308頁）中。13.3.6機動時間在工程網(wǎng)絡(luò)中每個作業(yè)的機動時間寫在代表該項作業(yè)的箭頭下面的括弧里(參看圖13.3)。在制定進度計劃時仔細考慮和利用工程網(wǎng)絡(luò)中的機動時間，往往能夠安排出既節(jié)省資源又不影響最終竣工時間的進度表。在圖13.4中的Gantt圖描繪了其中的一種方案。圖13.4舊木板房刷漆工程改進的Gantt圖之一這個簡單例子明顯說明了工程網(wǎng)絡(luò)比Gantt圖優(yōu)越的地方：它顯式地定義事件及作業(yè)之間的依賴關(guān)系，Gantt圖只能隱含地表示這種關(guān)系。但是Gantt圖的形式比工程網(wǎng)絡(luò)更簡單更直觀，為更多的人所熟悉，因此，應(yīng)該同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短。以上通過舊木板房刷新漆工程的簡單例子，介紹了制訂進度計劃的兩個重要工具和方法。軟件工程項目雖然比這個簡單例子復(fù)雜得多，但是計劃和管理的基本方法仍然是自頂向下分解，也就是把項目分解為若干個階段，每個階段再分解成許多更小的任務(wù)，每個任務(wù)又可進一步分解為若干個步驟等等。這些階段、任務(wù)和步驟之間有復(fù)雜的依賴關(guān)系，因此，工程網(wǎng)絡(luò)和Gantt圖同樣是安排進度和管理工程進展情況的強有力的工具。第13.2節(jié)中介紹的工作量估計技術(shù)可以幫助我們估計每項任務(wù)的工作量，根據(jù)人力分配情況，可以進一步確定每項任務(wù)的持續(xù)時間。從這些基本數(shù)據(jù)出發(fā)，根據(jù)作業(yè)之間的依賴關(guān)系，利用工程網(wǎng)絡(luò)和Gantt圖可以制定出合理的進度計劃，并且能夠科學(xué)地管理軟件開發(fā)工程的進展情況。軟件項目成功的關(guān)鍵是有高素質(zhì)的軟件開發(fā)人員。然而大多數(shù)軟件的規(guī)模都很大，單個軟件開發(fā)人員無法在給定期限內(nèi)完成開發(fā)工作，因此，必須把多名軟件開發(fā)人員合理地組織起來，使他們有效地分工協(xié)作共同完成開發(fā)工作。13.4人員組織為了成功地完成軟件開發(fā)工作，項目組成員必須以一種有意義且有效的方式彼此交互和通信。如何組織項目組是一個重要的管理問題，管理者應(yīng)該合理地組織項目組，使項目組有較高生產(chǎn)率，能夠按預(yù)定的進度計劃完成所承擔的工作。經(jīng)驗表明，項目組組織得越好，其生產(chǎn)率越高，而且產(chǎn)品質(zhì)量也越好。除了追求更好的組織方式之外，每個管理者的目標都是建立有凝聚力的項目組。一個有高度凝聚力的小組，由一批團結(jié)得非常緊密的人組成，他們的整體力量大于個體力量的總和。一旦項目組具有了凝聚力，成功的可能性就大大增加了?，F(xiàn)有的軟件項目組的組織方式很多，通常，組織軟件開發(fā)人員的方法，取決于所承擔的項目的特點、以往的組織經(jīng)驗以及管理者的看法和喜好。下面介紹3種典型的組織方式。民主制程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協(xié)商做出技術(shù)決策。因此，小組成員之間的通信是平行的，如果小組內(nèi)有n個成員，則可能的通信信道共有n(n-1)/2條。程序設(shè)計小組的人數(shù)不能太多,否則組員間彼此通信的時間將多于程序設(shè)計時間。此外,通常不能把一個軟件系統(tǒng)劃分成大量獨立的單元,因此,如果程序設(shè)計小組人數(shù)太多,則每個組員所負責開發(fā)的程序單元與系統(tǒng)其他部分的界面將是復(fù)雜的,不僅出現(xiàn)接口錯誤的可能性增加,而且軟件測試將既困難又費時間。13.4.1民主制程序員組一般說來，程序設(shè)計小組的規(guī)模應(yīng)該比較小,以2～8名成員為宜。如果項目規(guī)模很大,用一個小組不能在預(yù)定時間內(nèi)完成開發(fā)任務(wù),則應(yīng)該使用多個程序設(shè)計小組,每個小組承擔工程項目的一部分任務(wù)，在一定程度上獨立自主地完成各自的任務(wù)。系統(tǒng)的總體設(shè)計應(yīng)該能夠保證由各個小組負責開發(fā)的各部分之間的接口是良好定義的,并且是盡可能簡單的。小組規(guī)模小,不僅可以減少通信問題,而且還有其他好處。例如,容易確定小組的質(zhì)量標準,而且用民主方式確定的標準更容易被大家遵守;組員間關(guān)系密切,能夠互相學(xué)習等等。民主制程序員組通常采用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內(nèi)其他成員完成同樣的任務(wù)。在這樣的小組中，由全體討論協(xié)商決定應(yīng)該完成的工作，并且根據(jù)每個人的能力和經(jīng)驗分配適當?shù)娜蝿?wù)。民主制程序員組的主要優(yōu)點是，組員們對發(fā)現(xiàn)程序錯誤持積極的態(tài)度，這種態(tài)度有助于更快速地發(fā)現(xiàn)錯誤，從而導(dǎo)致高質(zhì)量的代碼。民主制程序員組的另一個優(yōu)點是，組員們享有充分民主，小組有高度凝聚力，組內(nèi)學(xué)術(shù)空氣濃厚，有利于攻克技術(shù)難關(guān)。因此，當有難題需要解決時，也就是說，當所要開發(fā)的軟件的技術(shù)難度較高時，采用民主制程序員組是適宜的。如果組內(nèi)多數(shù)成員是經(jīng)驗豐富技術(shù)熟練的程序員,那么上述非正式的組織方式可能會非常成功。在這樣的小組內(nèi)組員享有充分民主,通過協(xié)商,在自愿的基礎(chǔ)上作出決定,因此能夠增強團結(jié)、提高工作效率。但是,如果組內(nèi)多數(shù)成員技術(shù)水平不高,或是缺乏經(jīng)驗的新手,那么這種非正式的組織方式也有嚴重缺點：由于沒有明確的權(quán)威指導(dǎo)開發(fā)工程的進行,組員間將缺乏必要的協(xié)調(diào),最終可能導(dǎo)致工程失敗。為了使少數(shù)經(jīng)驗豐富、技術(shù)高超的程序員在軟件開發(fā)過程中能夠發(fā)揮更大作用，程序設(shè)計小組也可以采用下一小節(jié)中介紹的另外一種組織形式。美國IBM公司在20世紀70年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于下述幾點考慮：(1)軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗；(2)程序設(shè)計過程中有許多事務(wù)性的工作，例如，大量信息的存儲和更新；(3)多渠道通信很費時間，將降低程序員的生產(chǎn)率。13.4.2主程序員組主程序員組用經(jīng)驗多、技術(shù)好、能力強的程序員作為主程序員，同時，利用人和計算機在事務(wù)性工作方面給主程序員提供充分支持，而且所有通信都通過一兩個人進行。這種組織方式類似于外科手術(shù)小組的組織：主刀大夫?qū)κ中g(shù)全面負責，并且完成制訂手術(shù)方案、開刀等關(guān)鍵工作，同時又有麻醉師、護士長等技術(shù)熟練的專門人員協(xié)助和配合他的工作。此外，必要時手術(shù)組還要請其他領(lǐng)域的專家（例如，心臟科醫(yī)生或婦產(chǎn)科醫(yī)生）協(xié)助。上述比喻突出了主程序員組的兩個重要特性：（1）專業(yè)化。該組每名成員僅完成他們受過專業(yè)訓(xùn)練的那些工作。（2）層次性。主刀大夫指揮每名組員工作，并對手術(shù)全面負責。當時，典型的主程序員組的組織形式如圖13.5所示。該組由主程序員、后備程序員、編程秘書以及1~3名程序員組成。在必要的時候，該組還有其他領(lǐng)域的專家協(xié)助。圖13.5主程序員組的結(jié)構(gòu)主程序員組核心人員的分工如下所述：（1）主程序員既是成功的管理人員又是經(jīng)驗豐富、技術(shù)好、能力強的高級程序員，負責體系結(jié)構(gòu)設(shè)計和關(guān)鍵部分（或復(fù)雜部分）的詳細設(shè)計，并且負責指導(dǎo)其他程序員完成詳細設(shè)計和編碼工作。如圖13.5所示，程序員之間沒有通信渠道，所有接口問題都由主程序員處理。主程序員對每行代碼的質(zhì)量負責，因此，他還要對組內(nèi)其他成員的工作成果進行復(fù)查。（2）后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗，他協(xié)助主程序員工作并且在必要時（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。因此，后備程序員必須在各方面都和主程序員一樣優(yōu)秀，并且對本項目的了解也應(yīng)該和主程序員一樣深入。平時，后備程序員的工作主要是，設(shè)計測試方案、分析測試結(jié)果及獨立于設(shè)計過程的其他工作。（3）編程秘書負責完成與項目有關(guān)的全部事務(wù)性工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執(zhí)行源程序和測試用例。注意，上面介紹的是20世紀70年代初期的主程序員組組織結(jié)構(gòu)，現(xiàn)在的情況已經(jīng)和當時大不相同了，程序員已經(jīng)有了自己的終端或工作站，他們自己完成代碼的輸入、編輯、編譯、鏈接和測試等工作，無須由編程秘書統(tǒng)一做這些工作。典型的主程序員組的現(xiàn)代形式將在下一小節(jié)介紹。雖然圖13.5所示的主程序員組的組織方式說起來有不少優(yōu)點，但是，它在許多方面卻是不切實際的。首先，如前所述，主程序員應(yīng)該是高級程序員和優(yōu)秀管理者的結(jié)合體。承擔主程序員工作需要同時具備這兩方面的才能，但是，在現(xiàn)實社會中這樣的人才并不多見。通常，既缺乏成功的管理者也缺乏技術(shù)熟練的程序員。其次，后備程序員更難找。人們期望后備程序員像主程序員一樣優(yōu)秀，但是，他們必須坐在“替補席”上，拿著較低的工資等待隨時接替主程序員的工作。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作。第三，編程秘書也很難找到。專業(yè)的軟件技術(shù)人員一般都厭煩日常的事務(wù)性工作，但是，人們卻期望編程秘書整天只干這類工作。我們需要一種更合理、更現(xiàn)實的組織程序員組的方法，這種方法應(yīng)該能充分結(jié)合民主制程序員組和主程序員組的優(yōu)點，并且能用于實現(xiàn)更大規(guī)模的軟件產(chǎn)品。民主制程序員組的一個主要優(yōu)點，是小組成員都對發(fā)現(xiàn)程序錯誤持積極、主動的態(tài)度。但是，使用主程序員組的組織方式時，主程序員對每行代碼的質(zhì)量負責，因此，他必須參與所有代碼審查工作。由于主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工作就會把所發(fā)現(xiàn)的程序錯誤與小組成員的工作業(yè)績聯(lián)系起來，從而造成小組成員出現(xiàn)不愿意發(fā)現(xiàn)錯誤的心理。13.4.3現(xiàn)代程序員組解決上述問題的方法是，取消主程序員的大部分行政管理工作。前面已經(jīng)指出，很難找到既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工作，不僅解決了小組成員不愿意發(fā)現(xiàn)程序錯誤的心理問題，也使得尋找主程序員的人選不再那么困難。于是，實際的“主程序員”應(yīng)該由兩個人共同擔任：一個技術(shù)負責人，負責小組的技術(shù)活動；一個行政負責人，負責所有非技術(shù)性事務(wù)的管理決策。這樣的組織結(jié)構(gòu)如圖13.6所示。技術(shù)組長自然要參與全部代碼審查工作，因為他要對代碼的各方面質(zhì)量負責；相反，行政組長不可以參與代碼審查工作，因為他的職責是對程序員的業(yè)績進行評價。行政組長應(yīng)該在常規(guī)調(diào)度會議上了解每名組員的技術(shù)能力和工作業(yè)績。圖13.6現(xiàn)代程序員組的結(jié)構(gòu)在開始工作之前明確劃分技術(shù)組長和行政組長的管理權(quán)限是很重要的。但是，即使已經(jīng)做了明確分工，有時也會出現(xiàn)職責不清的矛盾。例如，考慮年度休假問題，行政組長有權(quán)批準某個程序員休年假的申請，因為這是一個非技術(shù)性問題，但是技術(shù)組長可能馬上否決了這個申請，因為已經(jīng)接近預(yù)定的項目結(jié)束日期，目前人手非常緊張。解決這類問題的辦法是求助于更高層的管理人員，對行政組長和技術(shù)組長都認為是屬于自己職責范圍內(nèi)的事務(wù)，制定一個處理方案。由于程序員組成員人數(shù)不宜過多，當軟件項目規(guī)模較大時，應(yīng)該把程序員分成若干個小組，采用圖13.7所示的組織結(jié)構(gòu)。該圖描繪的是技術(shù)管理組織結(jié)構(gòu)，非技術(shù)管理組織結(jié)構(gòu)與此類似。由圖可以看出，產(chǎn)品開發(fā)作為一個整體是在項目經(jīng)理的指導(dǎo)下進行的，程序員向他們的組長匯報工作，而組長則向項目經(jīng)理匯報工作。當產(chǎn)品規(guī)模更大時，可以適當增加中間管理層次。圖13.7大型項目的技術(shù)管理組織結(jié)構(gòu)把民主制程序員組和主程序員組的優(yōu)點結(jié)合起來的另一種方法，是在合適的地方采用分散做決定的方法，如圖13.8所示。這樣做有利于形成暢通的通信渠道，以便充分發(fā)揮每個程序員的積極性和主動性，集思廣益攻克技術(shù)難關(guān)。這種組織方式對于適合采用民主方法的那類問題（例如，研究性項目或遇到技術(shù)難題需要用集體智慧攻關(guān)）非常有效。盡管這種組織方式適當?shù)匕l(fā)揚了民主，但是上下級之間的箭頭（即管理關(guān)系）仍然是向下的，也就是說，是在集中指導(dǎo)下發(fā)揚民主。顯然，如果程序員可以指揮項目經(jīng)理，則只會引起混亂。圖13.8包含分散決策的組織方式概括地說，軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質(zhì)量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發(fā)標準以及任何專業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含特征相一致的程度。上述定義強調(diào)了下述的3個要點：13.5質(zhì)量保證

13.5.1軟件質(zhì)量（1）軟件需求是度量軟件質(zhì)量的基礎(chǔ)，與需求不一致就是質(zhì)量不高。（2）指定的開發(fā)標準定義了一組指導(dǎo)軟件開發(fā)的準則，如果沒有遵守這些準則，幾乎肯定會導(dǎo)致軟件質(zhì)量不高。（3）通常，有一組沒有顯式描述的隱含需求（例如，軟件應(yīng)該是容易維護的）。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質(zhì)量仍然是值得懷疑的。雖然軟件質(zhì)量是難于定量度量的軟件屬性，但是仍然能夠提出許多重要的軟件質(zhì)量指標(其中絕大多數(shù)目前還處于定性度量階段)。本節(jié)介紹影響軟件質(zhì)量的主要因素，這些因素是從管理角度對軟件質(zhì)量的度量?？梢园堰@些質(zhì)量因素分成3組，分別反映用戶在使用軟件產(chǎn)品時的3種不同傾向或觀點。這3種傾向是：產(chǎn)品運行、產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。圖13.9描繪了軟件質(zhì)量因素和上述3種傾向(或產(chǎn)品活動)之間的關(guān)系，表13.7（見書315頁）列出了軟件質(zhì)量因素的簡明定義。圖13.9軟件質(zhì)量因素與產(chǎn)品活動的關(guān)系軟件質(zhì)量保證（softwarequalityassurance,SQA）的措施主要有：基于非執(zhí)行的測試（也稱為復(fù)審或評審），基于執(zhí)行的測試（即以前講過的軟件測試）和程序正確性證明。復(fù)審主要用來保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量；基于執(zhí)行的測試需要在程序編寫出來之后進行，它是保證軟件質(zhì)量的最后一道防線；程序正確性證明使用數(shù)學(xué)方法嚴格驗證程序是否與對它的說明完全一致。13.5.2軟件質(zhì)量保證措施參加軟件質(zhì)量保證工作的人員，可以劃分成下述兩類：軟件工程師通過采用先進的技術(shù)方法和度量，進行正式的技術(shù)復(fù)審以及完成計劃周密的軟件測試來保證軟件質(zhì)量。SQA小組的職責，是輔助軟件工程師以獲得高質(zhì)量的軟件產(chǎn)品。其從事的軟件質(zhì)量保證活動主要是：計劃，監(jiān)督，記錄，分析和報告。簡而言之，SQA小組的作用是，通過確保軟件過程的質(zhì)量來保證軟件產(chǎn)品的質(zhì)量。1.技術(shù)復(fù)審的必要性正式技術(shù)復(fù)審的顯著優(yōu)點是，能夠較早發(fā)現(xiàn)軟件錯誤，從而可防止錯誤被傳播到軟件過程的后續(xù)階段。統(tǒng)計數(shù)字表明，在大型軟件產(chǎn)品中檢測出的錯誤，60%~70%屬于規(guī)格說明錯誤或設(shè)計錯誤，而正式技術(shù)復(fù)審在發(fā)現(xiàn)規(guī)格說明錯誤和設(shè)計錯誤方面的有效性高達75%。由于能夠檢測出并排除掉絕大部分這類錯誤，復(fù)審可大大降低后續(xù)開發(fā)和維護階段的成本。實際上，正式技術(shù)復(fù)審是軟件質(zhì)量保證措施的一種，包括走查（walkthrough)和審查（inspection）等具體方法。走查的步驟比審查少，而且沒有審查正規(guī)。2.走查走查組由4~6名成員組成。以走查規(guī)格說明的小組為例，成員至少包括一名負責起草規(guī)格說明的人，一名負責該規(guī)格說明的管理員，一位客戶代表，以及下階段開發(fā)組（在本例中是設(shè)計組）的一名代表和SQA小組的一名代表。其中SQA小組的代表應(yīng)該作為走查組的組長。為了能發(fā)現(xiàn)重大錯誤，走查組成員最好是經(jīng)驗豐富的高級技術(shù)人員。必須把被走查的材料預(yù)先分發(fā)給走查組每位成員。走查組成員應(yīng)該仔細研究材料并列出兩張表：一張表是他不理解的術(shù)語，另一張是他認為不正確的術(shù)語。走查組組長引導(dǎo)該組成員走查文檔，力求發(fā)現(xiàn)盡可能多的錯誤。走查組的任務(wù)僅僅是標記出錯誤而不是改正錯誤，改正錯誤的工作應(yīng)該由該文檔的編寫組完成。走查的時間最長不要超過2小時，這段時間應(yīng)該用來發(fā)現(xiàn)和標記錯誤，而不是改正錯誤。走查主要有下述兩種方式：（1）參與者驅(qū)動法。參與者按照事先準備好的列表，提出他們不理解的術(shù)語和認為不正確的術(shù)語。文檔編寫組的代表必須回答每個質(zhì)疑，要么承認確實有錯誤，要么對質(zhì)疑做出解釋。（2）文檔驅(qū)動法。文檔編寫者向走查組成員仔細解釋文檔。走查組成員在此過程中不時針對事先準備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質(zhì)疑。這種方法可能比第一種方法更有效，往往能檢測出更多錯誤。經(jīng)驗表明，使用文檔驅(qū)動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。3.審查審查的范圍比走查廣泛得多，它的步驟也比較多。通常，審查過程包括下述5個基本步驟：（1）綜述。由負責編寫文檔的一名成員向?qū)彶榻M綜述該文檔。在綜述會結(jié)束時把文檔分發(fā)給每位與會者。（2）準備。評審員仔細閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯誤的類型，并按發(fā)生頻率把錯誤類型分級，以輔助審查工作。這些列表有助于評審員們把注意力集中到最常發(fā)生錯誤的區(qū)域。（3）審查。評審組仔細走查整個文檔。和走查一樣，這一步的目的也是發(fā)現(xiàn)文檔中的錯誤，而不是改正它們。通常每次審查會不超過90分鐘。審查組組長應(yīng)該在一天之內(nèi)寫出一份關(guān)于審查的報告。（4）返工。文檔的作者負責解決在審查報告中列出的所有錯誤及問題。（5）跟蹤。組長必須確保所提出的每個問題都得到了圓滿的解決（要么修正了文檔，要么澄清了被誤認為是錯誤的條目）。必須仔細檢查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審查過程中返工量超過5%，則應(yīng)該由審查組再對文檔全面地審查一遍。通常，審查組由4人組成。組長既是審查組的管理人員又是技術(shù)負責人。審查組必須包括負責當前階段開發(fā)工作的項目組代表和負責下一階段開發(fā)工作的項目組代表，此外，還應(yīng)該包括一名SQA小組的代表。審查過程不僅步數(shù)比走查多，而且每個步驟都是正規(guī)的。審查的正規(guī)性體現(xiàn)在：仔細劃分錯誤類型，并把這些信息運用在后續(xù)階段的文檔審查中以及未來產(chǎn)品的審查中。審查是檢測軟件錯誤的一種好方法，利用審查可以在軟件過程的早期階段發(fā)現(xiàn)并改正錯誤，也就是說，能在修正錯誤的代價變得很昂貴之前就發(fā)現(xiàn)并改正錯誤。因此，審查是一種經(jīng)濟有效的錯誤檢測方法。4.程序正確性證明測試可以暴露程序中的錯誤，因此是保證軟件可靠性的重要手段；但是，測試只能證明程序中有錯誤，并不能證明程序中沒有錯誤。因此，對于保證軟件可靠性來說，測試是一種不完善的技術(shù)，人們自然希望研究出完善的正確性證明技術(shù)。一旦研究出實用的正確性證明程序(即，能自動證明其他程序的正確性的程序)，軟件可靠性將更有保證，測試工作量將大大減少。但是，即使有了正確性證明程序，軟件測試也仍然是需要的，因為程序正確性證明只證明程序功能是正確的，并不能證明程序的動態(tài)特性是符合要求的，此外，正確性證明過程本身也可能發(fā)生錯誤。正確性證明的基本思想是證明程序能完成預(yù)定的功能。因此，應(yīng)該提供對程序功能的嚴格數(shù)學(xué)說明，然后根據(jù)程序代碼證明程序確實能實現(xiàn)它的功能說明。在20世紀60年代初期，人們已經(jīng)開始研究程序正確性證明的技術(shù)，提出了許多不同的技術(shù)方法。雖然這些技術(shù)方法本身很復(fù)雜，但是它們的基本原理卻是相當簡單的。如果在程序的若干個點上，設(shè)計者可以提出關(guān)于程序變量及它們的關(guān)系的斷言，那么在每一點上的斷言都應(yīng)該永遠是真的。假設(shè)在程序的P1,P2,…，Pn等點上的斷言分別是a(1),a(2)，…，a(n)，其中a(1)必須是關(guān)于程序輸入的斷言，a(n)必須是關(guān)于程序輸出的斷言。為了證明在點Pi和Pi+1之間的程序語句是正確的，必須證明執(zhí)行這些語句之后將使斷言a(i)變成a(i+1)。如果對程序內(nèi)所有相鄰點都能完成上述證明過程，則證明了輸入斷言加上程序可以導(dǎo)出輸出斷言。如果輸入斷言和輸出斷言是正確的，而且程序確實是可以終止的(不包含死循環(huán))，則上述過程就證明了程序的正確性。人工證明程序正確性，對于評價小程序可能有些價值，但是在證明大型軟件的正確性時，不僅工作量太大，更主要的是在證明的過程中很容易包含錯誤，因此是不實用的。為了實用的目的，必須研究能證明程序正確性的自動系統(tǒng)。目前已經(jīng)研究出證明PASCAL和LISP程序正確性的程序系統(tǒng)，正在對這些系統(tǒng)進行評價和改進。現(xiàn)在這些系統(tǒng)還只能對較小的程序進行評價，毫無疑問還需要做許多工作，這樣的系統(tǒng)才能實際用于大型程序的正確性證明。任何軟件開發(fā)都是迭代過程，也就是說，在設(shè)計過程會發(fā)現(xiàn)需求說明書中的問題，在實現(xiàn)過程又會暴露出設(shè)計中的錯誤，……。此外，隨著時間推移客戶的需求也會或多或少發(fā)生變化。因此，在開發(fā)軟件的過程中，變化（或稱為變動）既是必要的，又是不可避免的。但是，變化也很容易失去控制，如果不能適當?shù)乜刂坪凸芾碜兓?，勢必造成混亂并產(chǎn)生許多嚴重的錯誤。13.6軟件配置管理軟件配置管理是在軟件的整個生命期內(nèi)管理變化的一組活動。具體地說，這組活動用來：①標識變化；②控制變化；③確保適當?shù)貙崿F(xiàn)了變化；④向需要知道這類信息的人報告變化。軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發(fā)生的，而配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標是，使變化更正確且更容易被適應(yīng)，在必須變化時減少所需花費的工作量。1.軟件配置項軟件過程的輸出信息可以分為3類：①計算機程序（源代碼和可執(zhí)行程序）；②描述計算機程序的文檔（供技術(shù)人員或用戶使用）；③數(shù)據(jù)（程序內(nèi)包含的或在程序外的）。上述這些項組成了在軟件過程中產(chǎn)生的全部信息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟件配置項。13.6.1軟件配置隨著軟件開發(fā)過程的進展，軟件配置項的數(shù)量迅速增加。不幸的是，由于前述的種種原因，軟件配置項的內(nèi)容隨時都可能發(fā)生變化。為了開發(fā)出高質(zhì)量的軟件產(chǎn)品，軟件開發(fā)人員不僅要努力保證每個軟件配置項正確，而且必須保證一個軟件的所有配置項是完全一致的?？梢园衍浖渲霉芾砜醋魇菓?yīng)用于整個軟件過程的軟件質(zhì)量保證活動，是專門用于管理變化的軟件質(zhì)量保證活動。2.基線基線是一個軟件配置管理概念，它有助于我們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為：已經(jīng)通過了正式復(fù)審的規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基礎(chǔ)，并且只有通過正式的變化控制過程才能改變它。簡而言之，基線就是通過了正式復(fù)審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現(xiàn)變化，但是，必須應(yīng)用特定的、正式的過程（稱為規(guī)程）來評估、實現(xiàn)和驗證每個變化。除了軟件配置項之外，許多軟件工程組織也把軟件工具置于配置管理之下，也就是說，把特定版本的編輯器、編譯器和其他CASE工具，作為軟件配置的一部分“固定”下來。因為當修改軟件配置項時必然要用到這些工具，為防止不同版本的工具產(chǎn)生的結(jié)果不同，應(yīng)該把軟件工具也基線化，并且列入到綜合的配置管理過程之中。軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它的主要任務(wù)是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告。具體來說，軟件配置管理主要有5項任務(wù)：標識、版本控制、變化控制、配置審計和報告。13.6.2軟件配置管理過程1.標識軟件配置中的對象為了控制和管理軟件配置項，必須單獨命名每個配置項，然后用面向?qū)ο蠓椒ńM織它們?？梢詷俗R出兩類對象：基本對象和聚集對象（可以把聚集對象作為代表軟件配置完整版本的一種機制）?；緦ο笫擒浖こ處熢诜治觥⒃O(shè)計、編碼或測試過程中創(chuàng)建出來的“文本單元”，例如，需求規(guī)格說明的一個段落、一個模塊的源程序清單或一組測試用例。聚集對象是基本對象和其他聚集對象的集合。每個對象都有一組能惟一地標識它的特征：名字、描述、資源表和“實現(xiàn)”。其中，對象名是無二義性地標識該對象的一個字符串。在設(shè)計標識軟件對象的模式時，必須認識到對象在整個生命周期中一直都在演化，因此，所設(shè)計的標識模式必須能無歧義地標識每個對象的不同版本。2.版本控制版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術(shù)，用戶能夠通過選擇適當?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。實現(xiàn)這個目標的方法是，把屬性和軟件的每個版本關(guān)聯(lián)起來，然后通過描述一組所期望的屬性來指定和構(gòu)造所需要的配置。上面提到的“屬性”，既可以簡單到僅是賦給每個配置對象的具體版本號，也可以復(fù)雜到是一個布爾變量串，其指明了施加到系統(tǒng)上的功能變化的具體類型。3.變化控制對于大型軟件開發(fā)項目來說，無控制的變化將迅速導(dǎo)致混亂。變化控制把人的規(guī)程和自動工具結(jié)合起來，以提供一個控制變化的機制。典型的變化控制過程如下：接到變化請求之后，首先評估該變化在技術(shù)方面的得失、可能產(chǎn)生的副作用、對其他配置對象和系統(tǒng)功能的整體影響以及估算出的修改成本。評估的結(jié)果形成“變化報告”，該報告供“變化控制審批者”審閱。所謂變化控制審批者既可以是一個人也可以由一組人組成，其對變化的狀態(tài)和優(yōu)先級做最終決策。為每個被批準的變化都生成一個“工程變化命令”，其描述將要實現(xiàn)的變化，必須遵守的約束以及復(fù)審和審計的標準。把要修改的對象從項目數(shù)據(jù)庫中“提?。╟heckout）”出來，進行修改并應(yīng)用適當?shù)腟QA活動。最后，把修改后的對象“提交（checkin）”進數(shù)據(jù)庫，并用適當?shù)陌姹究刂茩C制創(chuàng)建該軟件的下一個版本?！疤峤弧焙汀疤崛　边^程實現(xiàn)了變化控制的兩個主要功能——訪問控制和同步控制。訪問控制決定哪個軟件工程師有權(quán)訪問和修改一個特定的配置對象，同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會相互覆蓋。在一個軟件配置項變成基線之前，僅需應(yīng)用非正式的變化控制。該配置對象的開發(fā)者可以對它進行任何合理的修改（只要修改不會影響到開發(fā)者工作范圍之外的系統(tǒng)需求）。一旦該對象經(jīng)過了正式技術(shù)復(fù)審并獲得批準，就創(chuàng)建了一個基線。而一旦一個軟件配置項變成了基線，就開始實施項目級的變化控制?，F(xiàn)在，為了進行修改開發(fā)者必須獲得項目管理者的批準（如果變化是“局部的”），如果變化影響到其他軟件配置項，還必須得到變化控制審批者的批準。在某些情況下，可以省略正式的變化請求、變化報告和工程變化命令，但是，必須評估每個變化并且跟蹤和復(fù)審所有變化。4.配置審計為了確保適當?shù)貙崿F(xiàn)了所需要的變化，通常從下述兩方面采取措施：①正式的技術(shù)復(fù)審；②軟件配置審計。正式的技術(shù)復(fù)審（見13.5.2節(jié)）關(guān)注被修改后的配置對象的技術(shù)正確性。復(fù)審者審查該對象以確定它與其他軟件配置項的一致性，并檢查是否有遺漏或副作用。軟件配置審計通過評估配置對象的那些通常不在復(fù)審過程中考慮的特征（例如，修改時是否遵循了軟件工程標準，是否在該配置項中顯著地標明了所做的修改，是否注明了修改日期和修改者，是否適當?shù)馗铝怂邢嚓P(guān)的軟件配置項，是否遵循了標注變化、記錄變化和報告變化的規(guī)程），而成為對正式技術(shù)復(fù)審的補充。5.狀態(tài)報告書寫配置狀態(tài)報告是軟件配置管理的一項任務(wù)，它回答下述問題：①發(fā)生了什么事？②誰做的這件事？③這件事是什么時候發(fā)生的？④它將影響哪些其他事物？配置狀態(tài)變化對大型軟件開發(fā)項目的成功有重大影響。當大量人員在一起工作時，可能一個人并不知道另一個人在做什么。兩名開發(fā)人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾個人月的工作量根據(jù)過時的硬件規(guī)格說明開發(fā)軟件；察覺到所建議的修改有嚴重副作用的人可能還不知道該項修改正在進行。配置狀態(tài)報告通過改善所有相關(guān)人員之間的通信，幫助消除這些問題。美國卡內(nèi)基梅隆大學(xué)軟件工程研究所在美國國防部資助下于20世紀80年代末建立的能力成熟度模型（capabilitymaturitymodel，CMM)，是用于評價軟件機構(gòu)的軟件過程能力成熟度的模型。最初，建立此模型的目的主要是，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據(jù)，發(fā)展到后來，此模型又同時被應(yīng)用于許多軟件機構(gòu)內(nèi)部的過程改進活動中。13.7能力成熟度模型多年來，軟件危機一直困擾著許多軟件開發(fā)機構(gòu)。不少人試圖通過采用新的軟件開發(fā)技術(shù)來解決在軟件生產(chǎn)率和軟件質(zhì)量等方面存在的問題，但效果并不令人十分滿意。上述事實促使人們進一步考察軟件過程，從而發(fā)現(xiàn)關(guān)鍵問題在于對軟件過程的管理不盡人意。事實證明，在無規(guī)則和混亂的管理之下，先進的技術(shù)和工具并不能發(fā)揮出應(yīng)有的作用。人們逐漸認識到，改進對軟件過程的管理是消除軟件危機的突破口，再也不能忽視在軟件過程中管理的關(guān)鍵作用了。能力成熟度模型的基本思想是，由于問題是由我們管理軟件過程的方法不當引起的，所以新軟件技術(shù)的運用并不會自動提高軟件的生產(chǎn)率和質(zhì)量。能力成熟度模型有助于軟件開發(fā)機構(gòu)建立一個有規(guī)律的、成熟的軟件過程。改進后的軟件過程將開發(fā)出質(zhì)量更好的軟件，使更多的軟件項目免受時間和費用超支之苦。軟件過程包括各種活動、技術(shù)和工具，因此，它實際上既包括了軟件開發(fā)的技術(shù)方面又包括了管理方面。CMM的策略是，力圖改進對軟件過程的管理，而在技術(shù)方面的改進是其必然的結(jié)果。CMM在改進軟件過程中所起的作用主要是，指導(dǎo)軟件機構(gòu)通過確定當前的過程成熟度并識別出對過程改進起關(guān)鍵作用的問題，從而明確過程改進的方向和策略。通過集中開展與過程改進的方向和策略相一致的一組過程改進活動，軟件機構(gòu)便能穩(wěn)步而有效地改進其軟件過程，使其軟件過程能力得到循序漸進的提高。對軟件過程的改進，是在完成一個又一個小的改進步驟基礎(chǔ)上不斷進行的漸進過程，而不是一蹴而就的徹底革命。CMM把軟件過程從無序到有序的進化過程分成5個階段，并把這些階段排序，形成5個逐層提高的等級。這5個成熟度等級定義了一個有序的尺度，用以測量軟件機構(gòu)的軟件過程成熟度和評價其軟件過程能力，這些等級還能幫助軟件機構(gòu)把應(yīng)做的改進工作排出優(yōu)先次序。成熟度等級是妥善定義的向成熟軟件機構(gòu)前進途中的平臺，每個成熟度等級都為軟件過程的繼續(xù)改進提供了一個臺階。CMM對5個成熟度級別特性的描述，說明了不同級別之間軟件過程的主要變化。從“1級”到“5級”，反映出一個軟件機構(gòu)為了達到從一個無序的、混亂的軟件過程進化到一種有序的、有紀律的且成熟的軟件過程的目的，必須經(jīng)歷的過程改進活動的途徑。每一個成熟度級別都是該軟件機構(gòu)沿著改進其過程的途徑前進途中的一個臺階，后一個成熟度級別是前一個級別的軟件過程的進化目標。CMM的每個成熟度級別中都包含一組過程改進的目標，滿足這些目標后一個機構(gòu)的軟件過程就從當前級別進化到下一個成熟度級別；每達到成熟度級別框架的下一個級別，該機構(gòu)的軟件過程都得到一定程度的完善和優(yōu)化，也使得過程能力得到提高；隨著成熟度級別的不斷提高，該機構(gòu)的過程改進活動取得了更加顯著的成效，從而使軟件過程得到進一步的完善和優(yōu)化。CMM就是以上述方式支持軟件機構(gòu)改進其軟件過程的活動。CMM通過定義能力成熟度的5個等級，引導(dǎo)軟件開發(fā)機構(gòu)不斷識別出其軟件過程的缺陷，并指出應(yīng)該做哪些改進，但是，它并不提供做這些改進的具體措施。能力成熟度的5個等級從低到高依次是：初始級（又稱為1級），可重復(fù)級（又稱為2級），已定義級（又稱為3級），已管理級（又稱為4級）和優(yōu)化級（又稱為5級）。下面介紹這5個級別的特點。1.初始級軟件過程的特征是無序的，有時甚至是混亂的。幾乎沒有什么過程是經(jīng)過定義的（即沒有一個定型的過程模型），項目能否成功完全取決于開發(fā)人員的個人能力。處于這個最低成熟度等級的軟件機構(gòu)，基本上沒有健全的軟件工程管理制度，其軟件過程完全取決于項目組的人員配備，所以具有不可預(yù)測性，人員變了過程也隨之改變。如果一個項目碰巧由一個杰出的管理者和一支有經(jīng)驗、有能力的開發(fā)隊伍承擔，則這個項目可能是成功的。但是，更常見的情況是，由于缺乏健全的管理和周密的計劃，延期交付和費用超支的情況經(jīng)常發(fā)生，結(jié)果，大多數(shù)行動只是應(yīng)付危機，而不是完成事先計劃好的任務(wù)?？傊?，處于1級成熟度的軟件機構(gòu)，其過程能力是不可預(yù)測的，其軟件過程是不穩(wěn)定的，產(chǎn)品質(zhì)量只能根據(jù)相關(guān)人員的個人工作能力而不是軟件機構(gòu)的過程能力來預(yù)測。2.可重復(fù)級軟件機構(gòu)建立了基本的項目管理過程(過程模型),可跟蹤成本、進度、功能和質(zhì)量。已經(jīng)建立起必要的過程規(guī)范，對新項目的策劃和管理過程是基于以前類似項目的實踐經(jīng)驗，使得有類似應(yīng)用經(jīng)驗的軟件項目能夠再次取得成功。達到2級的一個目標是使項目管理過程穩(wěn)定，從而使得軟件機構(gòu)能重復(fù)以前在成功項目中所進行過的軟件項目工程實踐。處于2級成熟度的軟件機構(gòu)，針對所承擔的軟件項目已建立了基本的軟件管理控制制度。通過對以前項目的觀察和分析，可以提出針對現(xiàn)行項目的約束條件。項目負責人跟蹤軟件產(chǎn)品開發(fā)的成本和進度以及產(chǎn)品的功能和質(zhì)量，并且識別出為滿足約束條件所應(yīng)解決的問題。已經(jīng)做到軟件需求條理化，而且其完整性是受控制的。已經(jīng)制定了項目標準，并且軟件機構(gòu)能確保嚴格執(zhí)行這些標準。項目組與客戶及承包商已經(jīng)建立起一個穩(wěn)定的、可管理的工作環(huán)境。處于2級成熟度的軟件機構(gòu)的過程能力可以概括為，軟件項目的策劃和跟蹤是穩(wěn)定的，已經(jīng)為一個有紀律的管理過程提供了可重復(fù)以前成功實踐的項目環(huán)境。軟件項目工程活動處于項目管理體系的有效控制之下，執(zhí)行著基于以前項目的準則且合乎現(xiàn)實的計劃。3.已定義級軟件機構(gòu)已經(jīng)定義了完整的軟件過程（過程模型），軟件過程已經(jīng)文檔化和標準化。所有項目組都使用文檔化的、經(jīng)過批準的過程來開發(fā)和維護軟件。這一級包含了第2級的全部特征。在第3級成熟度的軟件機構(gòu)中，有一個固定的過程小組從事軟件過程工程活動。當需要時，過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟件項目的過程實例，并投入過程運作而開展有效的軟件項目工程實踐。同時，過程小組還可以推進軟件機構(gòu)的過程改進活動。在該軟件機構(gòu)內(nèi)實施了培訓(xùn)計劃，能夠保證全體項目負責人和項目開發(fā)人員具有完成承擔的任務(wù)所要求的知識和技能。處于3級成熟度的軟件機構(gòu)的過程能力可以概括為，無論是管理活動還是工程活動都是穩(wěn)定的。軟件開發(fā)的成本和進度以及產(chǎn)品的功能和質(zhì)量都受到控制，而且軟件產(chǎn)品的質(zhì)量具有可追溯性。這種能力是基于在軟件機構(gòu)中對已定義的過程模型的活動、人員和職責都有共同的理解。4.已管理級軟件機構(gòu)對軟件過程（過程模型和過程實例）和軟件產(chǎn)品都建立了定量的質(zhì)量目標，所有項目的重要的過程活動都是可度量的。該軟件機構(gòu)收集了過程度量和產(chǎn)品度量的方法并加以運用，可以定量地了解和控制軟件過程和軟件產(chǎn)品，并為評定項目的過程質(zhì)量和產(chǎn)品質(zhì)量奠定了基礎(chǔ)。這一級包含了第3級的全部特征。處于4級成熟度的軟件機構(gòu)的過程能力可以概括為，軟件過程是可度量的，軟件過程在可度量的范圍內(nèi)運行。這一級的過程能力允許軟件機構(gòu)在定量的范圍內(nèi)預(yù)測過程和產(chǎn)品質(zhì)量趨勢，在發(fā)生偏離時可以及時采取措施予以糾正，并且可以預(yù)期軟件產(chǎn)品是高質(zhì)量的。5.優(yōu)化級軟件機構(gòu)集中精力持續(xù)不斷地改進軟件過程。這一級的軟件機構(gòu)是一個以防止出現(xiàn)缺陷為目標的機構(gòu)，它有能力識別軟件過程要素的薄弱環(huán)節(jié)，并有足夠的手段改進它們。在這樣的機構(gòu)中，可以獲得關(guān)于軟件過程有效性的統(tǒng)計數(shù)據(jù)，利用這些數(shù)據(jù)可以對新技術(shù)進行成本/效益分析，并可以優(yōu)化出在軟件工程實踐中能夠采用的最佳新技術(shù)。這一級包含了第4級的全部特征。這一級的軟件機構(gòu)可以通過