軟件工程13-軟件項(xiàng)目管理

軟件工程

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

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

lnp+a2Out+a3Inq+a4Maf+a5Inf

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

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

i

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

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

17 E=aKLOCbfi

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

b=1.01+0.01

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

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

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

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

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

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

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

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

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

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

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

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

起點(diǎn)EST

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

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

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

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

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

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

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

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