軟件管理工程

軟件管理工程I.管理工程的重要性和意義II．項目管理III．配置管理1I.管理工程的重要性和意義管理是實現(xiàn)軟件工程基本目標的保證。軟件工程管理引起廣泛注意源于20世紀70年代中期，當時發(fā)現(xiàn)不成功的項目70%是因為管理不善而引起。20世紀90年代中期，美國的軟件開發(fā)仍然很難預(yù)測，大約只有10%的項目能夠在預(yù)定的費用和進度下交付。2II.項目管理1．管理的內(nèi)容2．管理過程的主要活動3管理的內(nèi)容 要完成的任務(wù)； 需要的資源（人、軟／硬件）； 花費的工作量（成本）；可能遇到的風(fēng)險；工作進度。4管理過程的活動

一。制定計劃二。度量三。估算四。風(fēng)險管理五。計劃實施、追蹤控制5一。軟件項目計劃的基本問題1。計劃的重要性2。誰負責(zé)以及何時制定計劃？3。項目計劃的特點4。項目計劃包括哪些子計劃？5。軟件過程和SPP6。SPP的動態(tài)性7。項目策劃的主要步驟61.計劃的重要性項目計劃是為實現(xiàn)預(yù)定目標而作的科學(xué)預(yù)測，以它為基準跟蹤和控制項目的開發(fā)它確定未來的行動方案和資源分配，引導(dǎo)項目的實施項目計劃的質(zhì)量是決定項目成敗、優(yōu)劣的關(guān)鍵因素之一72.誰負責(zé)以及何時制定計劃？項目經(jīng)理負責(zé)制定計劃，項目組成員參與。軟件項目開發(fā)計劃是指導(dǎo)項目的綱，應(yīng)盡早制定。在項目定義階段，只要明確了軟件項目的目標和軟件要實現(xiàn)的基本功能；只要項目人員明白用戶的意圖就應(yīng)制定。有時也稱初始計劃為基礎(chǔ)計劃。通過初始計劃的制定，項目經(jīng)理能熟悉項目工作的基本方面：范圍、需求、總的時間和里程碑、組織機構(gòu)、人員要求等。它確定了生存周期，管理過程、技術(shù)過程等。這些在項目過程中，變化不會太大。83.項目計劃的特點它是文檔化的，而不是只在經(jīng)理的腦袋里描述任務(wù)；如何作，包括資源，時間周期，可接受的偏差范圍等可讀性好模塊化足夠簡煉，讓人愿意看項目計劃中應(yīng)包括所有的項目管理問題94.項目計劃包括哪些子計劃？項目計劃中包括：SDP計劃－軟件開發(fā)計劃SQA計劃－軟件質(zhì)量保証計劃SCM計劃－配置管理計劃測試計劃風(fēng)險計劃培訓(xùn)計劃跟蹤計劃……105。軟件過程和SPP任何項目都有自己確定的過程。過程管理對軟件尤為重要。無論在CMM的哪個等級，都必須將過程文檔化。但一般項目確定的軟件過程描述不夠明確以致不能直接執(zhí)行。SDP中以各種方式（如索引）包含項目過程的描述，但建立項目過程并不是SPP的任務(wù)。SDP在項目已確定的軟件過程的基礎(chǔ)之上建立。項目的SDP在項目確定的軟件過程（將做什么和如何作）和項目的具體完成方式（例如，誰將按照什么進度生成哪個工作產(chǎn)品）之間建立聯(lián)系。例如，SCM、設(shè)計等。116。SPP的動態(tài)性眾所周知，項目策劃是基于當前已有的信息(包括過去的經(jīng)驗，當前項目的目標、范圍、組織結(jié)構(gòu)、資源等)，安排工作和進度，預(yù)測作業(yè)結(jié)果隨著項目的進展、信息的增多和理解的深入，預(yù)測會逐漸地接近實際，所以對任何類型的項目來說，計劃的修訂不可避免軟件項目計劃將不斷修訂，貫穿全生存周期(SPP活動3)；每次修訂應(yīng)按CMM中SPP-KPA的要求進行。127.項目策劃的主要步驟定義可交付產(chǎn)品(what,why,when,how)估計和策劃工作量和成本協(xié)商各方約定(who,where)安排進度和資源，使能按時交付編寫計劃Gantt圖和PERT圖13有關(guān)進度的安排和監(jiān)控幾個問題（1）任務(wù)分解結(jié)構(gòu)（2）甘特圖（3）PERT技術(shù)和CPM技術(shù)（4）開發(fā)模塊的任務(wù)網(wǎng)絡(luò)圖示例（5）分層任務(wù)網(wǎng)絡(luò)圖（6）關(guān)鍵路徑分析14（1）工作分解結(jié)構(gòu)

(WBS-workBreakdownstructure)概述WBS中的層次結(jié)構(gòu)WBS的構(gòu)造將兩者混合的WBS的例子WBS在項目“階段”的應(yīng)用WBS的局限性傳統(tǒng)的WBS及產(chǎn)品層次傳統(tǒng)的WBS的基本缺陷進化的WBS一個缺省的進化的WBS15概述WBS用于策劃（制定計劃），跟蹤、控制。WBS是項目計劃的“構(gòu)架”。在整個項目生命周期中，它必須用適當?shù)募毠?jié)等級封裝變更和進化。WBS以層次結(jié)構(gòu)組織項目活動的元素，將項目分解成易于管理的活動進化的WBS的組織方式與傳統(tǒng)的WBS的組織方式不同16WBS中的層次結(jié)構(gòu)產(chǎn)品的層次結(jié)構(gòu)指明各種軟件的構(gòu)件如何安置在軟件系統(tǒng)中反映軟件產(chǎn)品的基本結(jié)構(gòu)，由軟件設(shè)計者確定構(gòu)件有：例行程序(routine)、模塊、子系統(tǒng)等活動的層次結(jié)構(gòu)指明處理一個軟件構(gòu)件的各種方法合適時，活動層次的一部分可以運用到產(chǎn)品的任何一個層次可以將兩者混合WBS關(guān)注如何組織它們，以便能最適合項目的特征17WBS的構(gòu)造迭代式構(gòu)造構(gòu)造有意義的逐步細分的層次結(jié)構(gòu)向下細分到能實際作出策劃和控制的層次，但是不要太碎綜合自頂向下和由底向上兩種方法采用混合的產(chǎn)品/活動的層次結(jié)構(gòu)18將兩者混合的WBS的例子ACTIVITYBreak-upProductBreak-up19WBS在項目“階段”的應(yīng)用如果項目按階段進行對當前階段作詳細的分解對未來階段保留不動當知道更多細節(jié)時，進一步分解為更細的WBS20WBS的局限性不能顯示執(zhí)行任務(wù)的序列性不能顯示任務(wù)間的依賴性要用網(wǎng)絡(luò)描述進度安排21傳統(tǒng)的WBS及產(chǎn)品層次 系統(tǒng)需求和設(shè)計 子系統(tǒng)1 構(gòu)件11 需求 設(shè)計 編碼 測試 文檔 …（其它構(gòu)件的相似結(jié)構(gòu)） 構(gòu)件1n

需求 設(shè)計 編碼 測試 文檔 …（其它構(gòu)件的相似結(jié)構(gòu)）

集成和測試 測試計劃 測試過程準備 測試 測試報告 其它支持領(lǐng)域 配置控制 質(zhì)量保證 系統(tǒng)管理

子系統(tǒng)M

構(gòu)件M1

需求 設(shè)計 編碼 測試 文檔 …（其它構(gòu)件的相似結(jié)構(gòu)） 構(gòu)件Mn

需求 設(shè)計 編碼 測試 文檔 …（其它構(gòu)件的相似結(jié)構(gòu)）22傳統(tǒng)的WBS的基本缺陷(1)傳統(tǒng)的WBS的三個基本缺陷。(A)過早地圍繞產(chǎn)品設(shè)計進行了結(jié)構(gòu)化：如果計劃和產(chǎn)品構(gòu)架都已經(jīng)成熟，那么將二者緊密結(jié)合起來是合理的。如果計劃或是構(gòu)架需要改變時，松散的結(jié)合則更為合適。23傳統(tǒng)的WBS的基本缺陷(1)傳統(tǒng)的WBS的三個基本缺陷。(B)過早地在過于詳細或過于簡單的細節(jié)上進行分解、計劃和預(yù)算：大型軟件項目容易計劃過剩，小型軟件項目則容易計劃不足24傳統(tǒng)的WBS的基本缺陷(1)傳統(tǒng)的WBS的三個基本缺陷(C)傳統(tǒng)的WBS是項目相關(guān)的，交叉項目通常很難比較或者根本不可能比較：沒有標準的WBS，要在多個項目之間比較計劃、財務(wù)數(shù)據(jù)、進度數(shù)據(jù)、組織效率、成本趨勢、生產(chǎn)力趨勢或質(zhì)量趨勢是極其困難的。25傳統(tǒng)的WBS的基本缺陷(2)使用傳統(tǒng)的WBS的項目群組，多數(shù)無法回答下面這些簡單的問題，而這些問題對于有組織的過程改進是很關(guān)鍵的：(A)生產(chǎn)活動(需求、設(shè)計、實現(xiàn)、評估和實施)與日常管理活動(管理和環(huán)境)的比率如何？(B)花在返工活動的工作量的百分比是多少？(C)花在軟件基本設(shè)備(環(huán)境開銷)上的成本所占的百分比是多少？(D)生產(chǎn)性測試與(非生產(chǎn)性)集成的比率是多少？26進化的WBS進化的WBS圍繞過程框架組織計劃的元素，而不是圍繞產(chǎn)品框架組織這些元素。

27關(guān)于進化的WBS的建議第一級WBS元素是工作流(管理、環(huán)境、需求、設(shè)計、實現(xiàn)、評估和實施)。這些元素通常分配給單一的群組，它們構(gòu)成了用于項目的計劃和項目間比較的解剖結(jié)構(gòu)。第二級元素是為生命周期的階段而定義的(初始、細化、構(gòu)造和移交)。這些元素允許項目計劃以更加自然的方式精確地理解需求、構(gòu)架和內(nèi)在風(fēng)險。第三級元素是為生產(chǎn)各階段制品的活動而定義的。這些元素可能是結(jié)構(gòu)中級別最低的，用來對給定階段的離散制品進行成本結(jié)算，或許它們可以進一步分為幾個更低層次的活動一起共同生產(chǎn)一個制品。28一個推薦的進化的WBS(1)

A管理

AA初始階段管理

AAA業(yè)務(wù)案例開發(fā)

AAB細化階段發(fā)布規(guī)格說明

AAC細化階段WBS基線的制定

AAD軟件開發(fā)計劃

AAE初始階段項目控制和狀態(tài)評估

AB細化階段管理

ABA構(gòu)造階段發(fā)布規(guī)格說明

ABB構(gòu)造階段WBS基線的制定

ABC細化階段項目控制和狀態(tài)評估

AC構(gòu)造階段管理

ACA實施階段計劃

ACB實施階段WBS基線的制定

ACC構(gòu)造階段項目控制和狀態(tài)評估

AD移交階段管理

ADA下一代計劃

ADB移交階段項目控制和狀態(tài)評估

C 需求

CA初始階段需求開發(fā)

CAA可視化規(guī)格說明

CAB用況建模

CB細化階段需求基線的制定

CBA可視化基線的制定

CBB用況模型基線的制定

CC構(gòu)造階段需求維護

CD移交階段需求維護

D 設(shè)計

DA初始階段構(gòu)架原型

DB細化階段構(gòu)架基線的制定

DBA構(gòu)架設(shè)計建模

DBB設(shè)計演示計劃并實施

DBC軟件構(gòu)架描述

DC構(gòu)造階段設(shè)計建模

DCA構(gòu)架設(shè)計模型維護

DCB構(gòu)件設(shè)計建模

DD移交階段設(shè)計維護B環(huán)境

BA初始階段環(huán)境規(guī)格說明

BB細化階段環(huán)境基線的定制

BBA開發(fā)環(huán)境安裝與管理

BBB開發(fā)環(huán)境集成與定制工具制造

BBCSCO數(shù)據(jù)庫簡潔陳述

BC構(gòu)造階段環(huán)境維護

BCA開發(fā)環(huán)境安裝與管理

BCBSCO數(shù)據(jù)庫維護

BD移交階段環(huán)境維護

BDA開發(fā)環(huán)境維護與管理

BDBSCO數(shù)據(jù)庫維護

BDC維護環(huán)境包裝與移交一個缺省的進化的WBS是與過程框架(階段、工作流和制品)相一致的29一個推薦的進化的WBS(2)

E 實現(xiàn)

EA 初始階段構(gòu)件原型

EB 細化階段構(gòu)件實現(xiàn)

EBA關(guān)鍵構(gòu)件編碼演示集成

EC 構(gòu)造階段構(gòu)件實現(xiàn)

ECA初始階段發(fā)布構(gòu)件編碼與單機測試

ECBAlpha發(fā)布構(gòu)件編碼與單機測試

ECCBeta發(fā)布構(gòu)建編碼與單機測試

ECD構(gòu)件維護

ED 移交階段構(gòu)件維護

G 實施

GA 初始階段實施計劃

GB 細化階段實施計劃

GC構(gòu)造階段實施

GCA用戶手冊基線的制定

GD 移交階段實施

GDA產(chǎn)品向用戶移交F評估

FA 初始階段評估計劃

FB 細化階段評估

FBA測試建模

FBB構(gòu)架測試情景實現(xiàn)

FBC演示評估與發(fā)布說明書

FC 構(gòu)造階段評估

FCA初始發(fā)布評估與發(fā)布說明書

FCBAlpha發(fā)布評估與發(fā)布說明書

FCCBeta發(fā)布評估與發(fā)布說明書

FD 移交階段評估

FDA產(chǎn)品發(fā)布評估與發(fā)布說明書30一個推薦的進化的WBS(3)這個推薦的結(jié)構(gòu)示范了如何按照過程框架元素制訂計劃。它提供了一個框架，用于估計每個元素的成本和進度，在一個項目組織中分配元素，跟蹤開支。所示的結(jié)構(gòu)需要根據(jù)項目的以下特點剪裁。A.規(guī)模。更大型的項目需要更多層次和子結(jié)構(gòu)。31一個推薦的進化的WBS(4)B.組織結(jié)構(gòu)。包含子承包商或跨多個組織實體的項目可能會引進對不同WBS的分配限制。C.定制開發(fā)的程度。D.業(yè)務(wù)環(huán)境。合同性項目要求更加細致的管理和評估元素。開發(fā)商業(yè)產(chǎn)品的項目可能需要更加細致的實施元素基礎(chǔ)。局限在單個站點的應(yīng)用程序可能有一個很簡陋的實施元素或者一個精致的實施元素。E.經(jīng)驗。32（1）Gantt圖33（2）PERT技術(shù)和CPM技術(shù)(1)PERT和CPM技術(shù)是安排開發(fā)進度，制定軟件計劃的最常用的方法。兩種技術(shù)都是由較早的項目計劃活動中已經(jīng)產(chǎn)生的信息來驅(qū)動。計劃評價和評審技術(shù)(ProgramEvaluation&Review Technique-PERT)關(guān)鍵路經(jīng)(CriticalPathMethod–CPM)34PERT技術(shù)和CPM技術(shù)(2)任務(wù)網(wǎng)絡(luò)圖描述任務(wù)之間的依賴關(guān)系任務(wù)分解結(jié)構(gòu)—定義可針對整個產(chǎn)品，也可針對單個功能。兩種方法都提供項目工作定量劃分的工具，支持：確定關(guān)鍵路經(jīng)，決定項目持續(xù)時間的任務(wù)鏈通過統(tǒng)計模型為單個任務(wù)建立最有可能的時間估計計算為特定任務(wù)定義其時間“窗口”的邊界時間。35PERT技術(shù)和CPM技術(shù)(3)重要的邊界時間某個任務(wù)的最早開始時間是當其所有前驅(qū)任務(wù)在最短的可能時間中完成時某個任務(wù)的最晚開始時間是在不延遲項目最小完成時間的前提下，最晚啟動該任務(wù)的時間最早結(jié)束時間是最早開始時間加上任務(wù)持續(xù)時間最晚結(jié)束時間是最晚開始時間加上任務(wù)持續(xù)時間總浮動量是在保證進度的前提下，調(diào)度任務(wù)時所允許的富裕時間或回旋時間總和36（3）開發(fā)模塊的任務(wù)網(wǎng)絡(luò)圖示例A：公共模塊模塊B：新編模塊，依賴A的完成C：已有模塊，修復(fù)缺陷。依賴A的完成起點A編碼B編碼A測試A調(diào)試C理解C修改B測試B調(diào)試C測試C調(diào)試BC組裝測試04123657837（4）分層任務(wù)網(wǎng)絡(luò)圖起點A編碼B編碼A測試A調(diào)試C理解C修改B測試B調(diào)試C測試C調(diào)試BC組裝測試04123657838（5）關(guān)鍵路徑分析某軟件項目的PERT圖，圓框中的數(shù)字代表活動的周數(shù)，請找出關(guān)鍵路徑和完成項目的最短時間起點終點A3B6C5F5G7H4I6J6E3D639二軟件度量什么是軟件度量軟件度量的作用軟件度量的主要內(nèi)容40什么是軟件度量度量在現(xiàn)實世界中，把數(shù)字或符號指定給實體的某一屬性，以便根據(jù)已明確的規(guī)則來描述它們。軟件度量就是在軟件開發(fā)過程中把反映或影響軟件開發(fā)成本、開發(fā)效率、軟件質(zhì)量的各種數(shù)據(jù)測量出來并記錄下來。41軟件度量的作用為了有效地定量地進行管理。是進行計劃、估算、風(fēng)險分析、過程監(jiān)控、質(zhì)量監(jiān)控、評價等活動的基礎(chǔ)。是改進過程提高軟件質(zhì)量的重要手段。42軟件度量的主要內(nèi)容過程屬性的度量產(chǎn)品屬性度量43過程屬性的度量工作量度量工作時間度量資源費用度量事件度量44工作量度量工作產(chǎn)品(對象)標識：項目、文檔、模塊工作內(nèi)容： 調(diào)研、編寫文檔、編碼、測試、評審、改錯、項目例會工作成果量： 文檔頁數(shù)、代碼行數(shù)、模塊數(shù)、發(fā)現(xiàn)或糾正的錯誤數(shù)工作量： 人月、人周、人時45資源費用度量工作產(chǎn)品(對象)標識： 項目、模塊時間： 起止年/月/日資源：人數(shù)、設(shè)備數(shù)、支持工具數(shù)、資金數(shù)、場地面積46事件度量工作產(chǎn)品標識：項目發(fā)生時間：年/月/日事件描述：更改、偏離計劃（進度、費用）處理結(jié)果：更改/不更改、處理花費（損失）事件發(fā)生總數(shù)或頻率47產(chǎn)品屬性度量面向產(chǎn)品規(guī)模的度量。面向功能點的度量錯誤缺陷及改正率度量測試覆蓋率測量生產(chǎn)率、單位成本的計算48規(guī)模度量的基本方法因為估計受到許多因素的影響，如人、技術(shù)、環(huán)境、政策等，因此，軟件的規(guī)模、成本和工作量等都還沒有一個精確的計算方法。我們主要研究軟件規(guī)模的估計，它基于：軟件的代碼行(LineofCode–LOC)軟件的功能點(FunctionPoints-FP)軟件的用例(UseCase)49面向產(chǎn)品規(guī)模的度量工作產(chǎn)品標識：項目、模塊代碼行數(shù)：千行語句數(shù)、字符數(shù)、字節(jié)數(shù)注釋率：注釋語句數(shù)/代碼行數(shù)錯誤數(shù)／KLOC文檔頁數(shù)／KLOC成本／KLOCKLOC數(shù)／人月50代碼行的計算度量方法可執(zhí)行的行數(shù)可執(zhí)行的行數(shù)＋數(shù)據(jù)定義可執(zhí)行的行數(shù)＋數(shù)據(jù)定義＋注釋屏幕上輸入的物理行數(shù)邏輯分隔符號行計算的類型僅新行新的＋修改的新的＋修改的＋重用的所有交付的＋臨時支撐的代碼所有交付的＋臨時支撐的代碼和支持代碼51面向產(chǎn)品規(guī)模度量的特點代碼行是開發(fā)項目的生成品，容易計算；依賴于程序設(shè)計語言；必須在項目完成后才能得到數(shù)據(jù)。52面向功能的度量工作產(chǎn)品標識：項目、規(guī)模；功能點數(shù)FD；每個功能點的錯誤數(shù)；每個功能點的文檔數(shù)；每個功能點的成本；每人月完成的功能點數(shù)。53功能點計算的參數(shù)用戶輸入數(shù)據(jù)數(shù)：在系統(tǒng)運行時要用戶輸入的數(shù)據(jù)用戶輸出數(shù)據(jù)數(shù)：在系統(tǒng)運行時用戶要求輸出的數(shù)據(jù)用戶請求（查詢）數(shù)：用戶交互式有實時響應(yīng)的次數(shù)內(nèi)部文件數(shù)（數(shù)據(jù)庫）：數(shù)據(jù)庫中與本系統(tǒng)有交換的數(shù)據(jù)結(jié)構(gòu)數(shù)外部文件數(shù)：本系統(tǒng)運行時機器可讀的有交換的外系統(tǒng)數(shù)據(jù)結(jié)構(gòu)數(shù)54功能點計算方法

加權(quán)因數(shù)直接測量項 計數(shù)簡單中間復(fù)雜加權(quán)計數(shù)用戶輸入數(shù)據(jù)數(shù) 346用戶輸出數(shù)據(jù)數(shù) 45 7用戶請求（查詢）數(shù) 34 6內(nèi)部文件數(shù) 71015外部文件數(shù) 5710總計數(shù)功能點FP=總計數(shù)×（0.65+0.01×SUM(Fi)）Fi(i=1···14)為其它影響因素對計算功能點的校正值。Fi取值范圍從0到555影響因素56功能點度量的特點與程序設(shè)計語言無關(guān)在評估的早期就可知道數(shù)據(jù)依賴于主觀經(jīng)驗57調(diào)和不同的度量方法代碼行（軟件規(guī)模）和功能點數(shù)之間的關(guān)系依賴于程度設(shè)計語言和設(shè)計質(zhì)量。下表給出了不同程序設(shè)計語言中，建造一個功能點所需的平均代碼行數(shù)。程序設(shè)計語言LOC/FP(平均值)程序設(shè)計語言LOC/FP(平均值)匯編語言CCobolFortranPascalAda3201281051059070面向?qū)ο笳Z言第四代語言(4GLs)代碼生成器電子表格圖形語言(圖標)3020156458錯誤缺陷及改正率度量工作產(chǎn)品標識產(chǎn)品規(guī)模 千行代碼或功能點數(shù)測試級別單元測試、集成測試、(第幾遍測試)錯誤級別 分三級或五級錯誤個數(shù)改正個數(shù)錯誤率 錯誤數(shù)/軟件規(guī)模改正率 改正錯誤數(shù)/發(fā)現(xiàn)錯誤數(shù)59測試覆蓋率測量工作產(chǎn)品標識語句覆蓋率 試經(jīng)歷語句數(shù)/總語句數(shù)分支覆蓋率 測試經(jīng)歷支路數(shù)/總支路數(shù)簡單路徑覆蓋率 測試經(jīng)歷簡單路徑數(shù)/總簡單 路徑數(shù)60生產(chǎn)率、單位成本的計算生產(chǎn)率＝工作成果／工作量單位成本＝資源消耗折算成的成本（元）／產(chǎn)生的成果（最終成果）61七個核心度量元概述度量元目的視角工作和進展迭代計劃，計劃與實際情況，管理指標SLOC，功能點，對象點，情景，測試用例，SCOs(SoftwareChangeOrder)預(yù)算成本和開支財務(wù)洞察，計劃與實際對比，管理指標每月的成本，每月的全職人員，實際花費占預(yù)算的百分比人員結(jié)構(gòu)和群組動力學(xué)計劃資源與實際資源對比，雇傭率，離職率每月增加的人數(shù)，每月離職的人數(shù)變更量和穩(wěn)定性迭代計劃，進度收斂的管理指標打開的SCO和關(guān)閉的SCO，按類型(0,1,2,3,4)和發(fā)布/構(gòu)件/子系統(tǒng)分類。變更范圍和模塊度收斂，軟件廢品，質(zhì)量指標每次變更返工的SLOC，按類型(0,1,2,3,4)和發(fā)布/構(gòu)件/子系統(tǒng)分類。返工和適應(yīng)性收斂，軟件返工，質(zhì)量指標每次變更的平均小時數(shù)，按類型(0,1,2,3,4)和按發(fā)布/構(gòu)件/子系統(tǒng)分類。平均無故障時間和成熟度測試覆蓋/合適性，使用的健壯性，質(zhì)量指標故障計數(shù)，故障發(fā)生前的測試小時數(shù)，按發(fā)布/構(gòu)件/子系統(tǒng)分類。62三。軟件估計軟件估計的基本問題基本估計方法CMM對估計的要求規(guī)模度量的基本方法COCOMO模型面向功能點的估計加權(quán)平均法Delphi估計法63軟件估計的基本問題(1)

軟件估計過程軟件估計過程由如下的步驟組成：估計規(guī)模；估計成本和工作量；估計進度；估計關(guān)鍵計算機資源；評估風(fēng)險；審查/批準；跟蹤與報告估計；度量與改進過程。64軟件估計的基本問題(2)

進行估計時應(yīng)注意的問題1。至少使用兩種方法進行估計，以提供交叉檢查單獨估計的手段，并增加總估計的可信度。至少由兩個人進行估計。對于大型項目，應(yīng)有三個或更多人參加估計。2。在項目的早期，應(yīng)完成手工估計，并應(yīng)使估計者理解自動工具使用的過程和參數(shù)。在完成手工估計后，再使用自動工具進行一次估計，以便自動工具不會影響手工估計。在使用自動工具時，如果可能，應(yīng)校準模型，以更好地反映來自項目域的歷史數(shù)據(jù)，從而可以改進結(jié)果。65軟件估計的基本問題(2)

進行估計時應(yīng)注意的問題3。應(yīng)該比較兩個估計的結(jié)果，對于任何不一致都要解釋其原因。多大的不一致是可接受的，取決于項目所處生命周期的階段。項目的早期，在20%以內(nèi)的估計是合理的。隨著項目成熟，估計應(yīng)該趨于集中。4。這種比較的方法也應(yīng)在規(guī)模估計和進度估計時使用。所有假設(shè)和輸入應(yīng)該文檔化，并歸入軟件估計文件(SEF)。66軟件估計的基本問題(3)

軟件估計的動態(tài)性軟件估計是制定軟件計劃的基礎(chǔ)。軟件估計是一個持續(xù)過程，應(yīng)該用于項目的整個生命周期。67基本估計方法自頂向下與由底向上相結(jié)合自頂向下：整體->階段->工作單元。估計工作量小，結(jié)果有盲目性。由底向上：工作單元->階段->整體。容易拉掉一些管理工作量，結(jié)果易偏低。差別估計：與歷史項目比較。集中上述兩方法，有時不容易找到相似的項目。

只有對項目選定一種（或幾種）能夠改進的估計方法，并將多次估計的結(jié)果進行比較，才能積累經(jīng)驗和數(shù)據(jù)，估計才能越來越準確。68由底向上的估計法當一個待解決的問題過于復(fù)雜時，可以把它進一步分解(WBS)，直到分解后的子問題變得容易解決為止。然后分別解決每一個子問題。從而能根據(jù)歷史數(shù)據(jù)估算出每個子功能的規(guī)模。例如把問題逐級分解直到分解成“錄入功能”、“計算功能”、“排序功能”、“報表生成功能”、“……”，使軟件人員對每個問題都能較容易地映射到過去的經(jīng)驗，將這些子問題的解答綜合起來，從而得到原問題的解答。69成本和進度的估計過程(1)

自頂而下的方法項目計劃需要從兩個視角考慮。第一個是向前觀望、自頂而下的方法。從一個普通的需求和限制開始，得到一個宏觀級別的預(yù)算和進度，然后，將這些元素細分到較低級別預(yù)算和中間里程碑。從這個視角，會發(fā)生下面的計劃序列：1。軟件項目經(jīng)理（和其他人）開發(fā)出項目所需的規(guī)模、過程、環(huán)境、開發(fā)人員和質(zhì)量的全局描述。2。使用軟件成本估計模型，在宏觀級別上估計整體工作量和制定進度。

70成本和進度的估計過程(1)

自頂而下的方法3。SPM使用上述指南將估計的工作量分配到第一級WBS中，將進度劃分成主里程碑日期，將工作量分配給人員結(jié)構(gòu)剖面圖。此刻，便有了一個項目級的計劃。4。下一步，子項目經(jīng)理負責(zé)將每一個WBS元素劃分到更低的級別，盡量使其滿足頂層分配、人員結(jié)構(gòu)剖面圖和主里程碑日期的限制。71成本和進度的估計過程(2)

由底向上的方法第二個視角是向后觀望、由底向上的方法。從終點開始思考，分析微觀級別的預(yù)算和進度，綜合考慮這些元素，制定出更高級別預(yù)算和中間里程碑。這種方法由底向上制定和填充WBS。從這個視角，會發(fā)生下面的計劃序列：1。將最低級別的WBS元素細化成細節(jié)任務(wù)，相關(guān)的WBS元素的管理人員根據(jù)這些任務(wù)估計預(yù)算和進度。這些估計與項目相關(guān)參數(shù)結(jié)合得非常緊密。2。在較高級別預(yù)算和里程碑中結(jié)合并集成估計。需要均衡估計者的 個人建議，形成一致的磋商基礎(chǔ)72成本和進度的估計過程(3)

－－兩種方法互向校正將由底向上的結(jié)果與自頂向下的預(yù)算和進度里程碑進行比較。評估其區(qū)別并進行校正，最后取得一致。73CMM對估計的要求1。所有可靠的估計技術(shù)均依靠歷史數(shù)據(jù)；歷史數(shù)據(jù)愈多，估計愈精確。2。從CMML2開始估計，不要求精確，但要求能不斷改進。CMM的核心思想是不斷學(xué)習(xí)，不斷改進。因而：要有文檔化估計規(guī)程要從現(xiàn)有的項目開始每次迭代均應(yīng)有所改進

74CMM對估計的要求3。盡量使用數(shù)據(jù)，特別是要積累自己的數(shù)據(jù)。4。估計要經(jīng)常進行。在項目生命周期內(nèi)，隨著信息的增加應(yīng)不斷精化估計。因而在項目進程中，要不斷修訂計劃，每次修訂必須重新進行估計。75初始估計數(shù)據(jù)的選擇1。對于數(shù)據(jù)，在CMML2的估計規(guī)程中只要求“如果有的話，使用歷史數(shù)據(jù)”。所以起步時，只要選定方法，進行估計就是了。2。初始數(shù)據(jù)的來源：如有自己項目的數(shù)據(jù)，則用自己的數(shù)據(jù)；否則用本組織的數(shù)據(jù)。如果無組織的數(shù)據(jù)，則可依次選用本地區(qū)的數(shù)據(jù)、本國行業(yè)的數(shù)據(jù)、國際上的行業(yè)數(shù)據(jù)。

76初始估計數(shù)據(jù)的選擇3。CMML2的SPP的活動15要求建立一個數(shù)據(jù)庫，記錄項目估計數(shù)據(jù)，包括計劃時用的數(shù)據(jù)、再計劃時用的數(shù)據(jù)。為使數(shù)據(jù)可用，必須記錄估計的假設(shè)，例如所采用的估計模型、模型參數(shù)、任務(wù)的描述等。77制定軟件計劃時的估計對工作量，不僅需要知道總的估計，而且需要知道它按階段的分布情況以及在每一階段中按角色的分布情況。78制定軟件計劃時的估計基于歷史數(shù)據(jù)的實例(Infosys)階段工作量的％工作量需求分析414設(shè)計2068構(gòu)造40136測試1034驗收測試414項目管理827培訓(xùn)517其他930總計10034079CMML2中的估計對象及其相互關(guān)系1。估計對象有規(guī)模、工作量、成本、進度、CCR、風(fēng)險、設(shè)施和支持工具等。在作項目計劃時，就應(yīng)對待開發(fā)軟件的這些對象進行估計。2。其中規(guī)模是源，如果沒有對規(guī)模的值，就無法知道項目的工作量，就無法計劃開發(fā)進度和所需的資源。80CMML2中的估計對象及其相互關(guān)系3。而規(guī)模又取決于需求，因而估計要從估計需求開始。如果需求變更，則各項估計都要作相應(yīng)的變更。4。在CMML2中，并不要求估計缺陷，但要求記錄缺陷的類型和數(shù)值；在CMML3中，既要求估計缺陷，也要求記錄缺陷的類型和數(shù)值。5。一般這些量之間有一定的關(guān)系，具體值由歷史數(shù)據(jù)確定。當缺乏歷史數(shù)據(jù)時，可分別估計多個量，以便相互驗證。81程序規(guī)模的估計把新程序按程序的規(guī)模等級與從前編寫的程序排列判斷新程序的規(guī)?？赡苈溆趶那熬帉懙某绦虻哪膫€規(guī)模范圍，進而估計出可能的代碼行。程序的需求模塊1（?。┠K3（大）模塊2（稍大）模塊5（中）模塊4（較大）原程序1（80）原程序3（100）原程序4（60）原程序5（40）原程序2（30）原程序6（10）模塊6（中偏小）需求2需求1需求3需求4需求582編寫程序的效率度量程序規(guī)模的方法是統(tǒng)計源程序有多少行(LOC)。編程效率是指單位時間內(nèi)編寫的代碼行數(shù)。估計編寫某個程序所用的時間時，根據(jù)以前編寫類似程序所用的時間進行估計。隨著經(jīng)驗的增加，編寫一行程序所用的時間將會有很大的變化，應(yīng)該以分鐘/代碼行這個速率進行跟蹤，并且以最近5～10個程序所獲得的數(shù)據(jù)為依據(jù)進行估計。83從程序規(guī)模導(dǎo)出工作量從程序規(guī)?？梢詫?dǎo)出工作量。估計的一般步驟：工作效率的度量－分鐘/代碼行數(shù)軟件規(guī)模的度量–代碼行數(shù)工作量的度量–分鐘程序可能會有多少代碼行編寫每行代碼需要多少分鐘計算出總共需要的時間84

COCOMO模型當今有幾個軟件成本模型在使用中。其中一個流行的的軟件成本模型就是由BarryBoehm開發(fā)的構(gòu)造型成本模型（COnstructiveCOstModel，COCOMO）。針對不同類型的軟件有不同模式（1）組織模式：較小的、簡單的軟件項目，有良好應(yīng)用經(jīng)驗的小型項目組，針對一組不是很嚴格的需求展開的；85

COCOMO模型（2）半分離模式：中等軟件項目（在規(guī)模和復(fù)雜性上），具有不同經(jīng)驗的項目組必須滿足嚴格的及不嚴格的需求（如一個事務(wù)處理系統(tǒng)，對于終端硬件和數(shù)據(jù)庫軟件有明確要求）；（3）嵌入模式：必須在一組嚴格的硬件、軟件及操作下開發(fā)的軟件項目（如飛機的航空控制系統(tǒng)）。86原始的COCOMO估計公式這些是原始的COCOMO模型的成本估計關(guān)系：組織模式 Effort=3.2EAF(Size)1.05 Time（Man-Month）=2.5(Effort)0.38半分離模式 Effort=3.0EAF(Size)1.12 Time（Man-Month）=2.5(Effort)0.35嵌入模式 Effort=2.8EAF(Size)1.2 Time（Man-Month）=2.5(Effort)0.3287公式中參數(shù)的意義（1)Effort=人月的數(shù)量(2)EAF=15個工作量調(diào)整因子的乘積（見表1），其值通常在0.5到1.5之間。它代表多個參數(shù)的綜合效果，這些參數(shù)使得項目可以特征化并根據(jù)COCOMO數(shù)據(jù)庫中的項目規(guī)格化。每個參數(shù)可以定為：很低，低，正常，高，很高。每個參數(shù)設(shè)置的效。(3)Size=交付的源指令的數(shù)量（以千行代碼KLOC為單位）

88公式中參數(shù)的意義(4)最終產(chǎn)品的過程的內(nèi)在的規(guī)模經(jīng)濟指數(shù)，特別是避免無附加值活動（返工、官僚主義的拖延和溝通開銷）的過程能力(5)Time的指數(shù)P2=刻畫在管理一個軟件開發(fā)工作中內(nèi)在的慣性和并行性的指數(shù)89COCOMO項目特征參數(shù)標識符工作量調(diào)整因子參數(shù)范圍潛在的影響RELY需要的可靠性0.75–1.401.87DATA數(shù)據(jù)庫大小0.94–1.161.23CPLX產(chǎn)品復(fù)雜度0.70–1.652.36TIME執(zhí)行時間限制1.00–1.661.66STOR主存限制1.00–1.561.56VIRT虛擬機變動性0.87–1.301.49TURN計算機往返時間0.87–1.151.32ACAP分析能力1.46–0.712.06AEXP應(yīng)用經(jīng)驗1.29–0.821.57PCAP程序員能力1.42–0.702.03

VEXP 虛擬機經(jīng)驗1.21–0.901.34LEXP語言經(jīng)驗1.14–0.951.20MODP現(xiàn)代實踐的使用1.24–0.821.51TOOL軟件工具的使用1.24–0.831.49SCED需要的開發(fā)進度1.23–1.101.2390在COCOMO中缺省的WBS活動預(yù)算（％）注解需求分析4產(chǎn)品設(shè)計12編程 44包括詳細設(shè)計、編碼、單元測試和集成測試計劃6確認和驗證14項目職責(zé)7項目辦公室的職能（管理和經(jīng)營）CM和QA7手冊編寫691加權(quán)平均法當其它方法都不可行時，根據(jù)經(jīng)驗和歷史數(shù)據(jù)，計劃人員對每個功能按最佳的、可能的、悲觀的三種情況給出LOC或FP估計值，記作：a、m、b。當這些值的范圍確定之后，計算出LOC或FP的期望值E： E=(a+4m+b)/6其中可能的估計值m是加權(quán)最重的，并遵循貝塔概率分布。知覺和經(jīng)驗是重要的，也應(yīng)交叉使用其它方法。92加權(quán)平均法的估計規(guī)程(1)首先作出以下三種估計：非?？赡艿闹祎m，最樂觀的值to，最悲觀的值tp。再使用公式計算平均值=(to+4tm+tp)/6計算標準偏差和方差的值：標準偏差=(tp-to)/6方差=((tip-to)/6)293加權(quán)平均法的估計規(guī)程(2)利用方差和概率分布的概念，可得到平均值落在一個區(qū)間內(nèi)的概率:為預(yù)期平均值，概率是50%左右擴大一個標準偏差，概率是84.0%左右擴大兩個標準偏差，概率是97.7%左右擴大三個標準偏差，概率是99.9%有時公式中再引進一個復(fù)雜度乘積因子。94

Delphi估計法當許多專家基于相同假設(shè)獨立地作出估計，該估計多半是正確的必須確保專家對相同的正確假設(shè)進行工作95Delphi估計規(guī)程(1)Delphi估計規(guī)程如下：組織估計群組估計專家(例如，4-6個有關(guān)項目經(jīng)理或資深專家)作者估計協(xié)調(diào)者2. 作者陳述待待估計的系統(tǒng)3. 作者和專家一起識別作業(yè)和假設(shè)4. 作者和專家一起就可接收的估計差異水準達成一致(例如20%)協(xié)調(diào)者整理一份群組所決定的作業(yè)清單，發(fā)給每個專家96Delphi估計規(guī)程(2)6. 針對每個作業(yè)，專家獨立地對每個作業(yè)作出估計(無討論/咨詢)，將估計交給協(xié)調(diào)者協(xié)調(diào)者對如下表格作出綜合：協(xié)調(diào)者將綜合表發(fā)給全部專家和作者當%差別(variance)大于可接受水平時，專家與作者討論作業(yè)和假定。不討論估計值。某些作業(yè)可能作進一步分解或合并返回步驟5；繼續(xù)工作直到全部作業(yè)處在可接受的水平之內(nèi)作業(yè)最小估計最大估計平均估計%差別(VAR)接受/不接受97Delphi估計規(guī)程(3)Delphi估計法成功的關(guān)鍵因素：絕對不討論估計。討論作業(yè)和假設(shè)。估計是保密的，估計者不知道相互的估計。應(yīng)至少有三個估計者。將項目分解到小的作業(yè)(約20個人日)。98四。風(fēng)險管理風(fēng)險策略風(fēng)險特性風(fēng)險管理活動99風(fēng)險策略被動式：風(fēng)險發(fā)生后才采取措施，是“救火模式”。主動式：在項目開發(fā)前就標識出潛在的風(fēng)險，有計劃地管理風(fēng)險。主要目標是預(yù)防風(fēng)險。必要時加以控制，減輕影響。100風(fēng)險特性不確定性：刻劃風(fēng)險的事件可能發(fā)生也可能不發(fā)生；即，沒有100％發(fā)生的風(fēng)險（100％發(fā)生的風(fēng)險是加在項目上的約束）。損失：如果風(fēng)險變成了現(xiàn)實，就會產(chǎn)生惡性后果或損失。101活動風(fēng)險識別風(fēng)險估計風(fēng)險評估風(fēng)險駕馭和監(jiān)控102風(fēng)險識別根據(jù)歷史數(shù)據(jù)及經(jīng)驗，標識相關(guān)的風(fēng)險，列出全部風(fēng)險項S1，S2…，Sn。項目風(fēng)險識別技術(shù)風(fēng)險識別商業(yè)風(fēng)險103項目風(fēng)險識別項目風(fēng)險識別是要找出潛在的預(yù)算、進度、個人（包括人員和組織）、資源、用戶和需要方面的問題，以及它們對軟件項目的影響。如項目復(fù)雜性、規(guī)模和結(jié)構(gòu)等都可構(gòu)成風(fēng)險因素。104技術(shù)風(fēng)險識別技術(shù)風(fēng)險識別是要找出潛在設(shè)計、實現(xiàn)、接口、檢驗和維護方面的問題。規(guī)格說明的多義性、技術(shù)上的不確定性、技術(shù)陳舊、最新技術(shù)（不成熟）也是風(fēng)險因素。105商業(yè)風(fēng)險識別商業(yè)風(fēng)險有：(1)建立的軟件不是真正所想要的；(2)建立的軟件不適合整個軟件產(chǎn)品戰(zhàn)略；(3)銷售部門不清楚如何推銷這種軟件；(4)失去上級管理部門的支持；(5)失去預(yù)算或人員的承諾（預(yù)算風(fēng)險）。106人員風(fēng)險識別人員風(fēng)險有：(1)缺乏優(yōu)秀人才；(2)缺乏配套人才；(3)人員不夠；(4)人員對分配工作缺乏興趣；(5)人員流動過快。(6)人員意外缺勤（因病、因事）(7)人員缺乏足夠培訓(xùn)。107開發(fā)環(huán)境風(fēng)險(1)是否有可用的軟件支持工具（項目管理工具、配置管理工具、測試工具、……）。(2)設(shè)備是否陳舊。設(shè)備意外損壞。(3)是否發(fā)生病毒，使開發(fā)環(huán)境癱瘓。108風(fēng)險估計估計風(fēng)險發(fā)生的可能性。估計風(fēng)險可能產(chǎn)生的結(jié)果。建立一個尺度或標準來表示一個風(fēng)險的可能性；可以使用概率尺度表，其值分為：極罕見的、罕見的、普通的、可能的、極可能的。描述風(fēng)險的結(jié)果，分出影響的類別：性能、支持、成本、進度。估計風(fēng)險對項目和產(chǎn)品的影響；影響可分為4級：災(zāi)難性的；嚴重性的；輕微的；可忽略的。109風(fēng)險評價在項目進行中，進一步檢驗在風(fēng)險估計時所得到的估計的準確性，對已暴露的風(fēng)險進行優(yōu)先排隊，考慮控制和（或）消除可能出現(xiàn)風(fēng)險的方法。定義風(fēng)險參考水平值：對前述風(fēng)險影響類別——性能、支持、成本、進度分別（或組合）制定一個參考水平，即性能下降，支持困難、成本增加、進度延遲到某個程度（水平）項目被迫中止。110風(fēng)險駕馭和監(jiān)控

風(fēng)險駕馭是指利用某些技術(shù)，及某些項目管理方法等設(shè)法避開或轉(zhuǎn)移風(fēng)險。風(fēng)險監(jiān)控： 1）

做風(fēng)險因素跟蹤； 2）

進行風(fēng)險再估計； 3）

收集可用于將來的風(fēng)險分析的信息。111五。項目計劃實施追蹤和控制

追蹤控制目的：注意并發(fā)現(xiàn)軟件工程過程實際進展與計劃、標準（規(guī)范）之間的偏離，采取適當措施進行處理。112追蹤周報、月報。定期舉行項目狀態(tài)會議。在會上，報告進展遇到的問題。評價軟件工程過程中所產(chǎn)生的所有評審的結(jié)果。確定由項目的計劃進度所安排的正式的里程碑。比較每一個任務(wù)的實際開始時間和計劃開始時間。與開發(fā)人員交談，得到對開發(fā)進展和剛冒頭的問題的客觀評價。113控制

當問題出現(xiàn)的時候，項目管理人員必須實行控制以盡可能快地排解它們。在問題領(lǐng)域可能需要一些追加資源；人員可能要重新部署，或者項目進度要重新調(diào)整。114III.軟件配置管理

SoftwareConfigurationManagement

2023/1/13115軟件配置管理一。為什么要進行配置管理二。軟件配置管理的基本概念三。軟件配置管理的主要活動四。如何進行配置管理116一為什么要進行配置管理軟件配置管理的意義軟件規(guī)模不斷增大，中間產(chǎn)品多，管理困難。軟件變更是不可避免的，而變更更加劇了項目中軟件工程師間的混亂。配置管理協(xié)調(diào)軟件開發(fā)使得混亂減到最小的程度配置管理建立和維護在整個軟件生存周期中項目軟件產(chǎn)品的完整性、一致性和可追遡性。2023/1/13117二軟件配置管理的基本概念1。軟件配置管理2。軟件配置3。配置項4。配置標識5。里程碑、基線6。版本控制7。變更控制8。軟件配置管理過程1181。什么叫配置管理配置管理是一種對軟件項進行標識、組織和控制修改的管理工作和技術(shù)。是協(xié)調(diào)軟件開發(fā)使得混亂減到最小的技術(shù)。1192。軟件配置組成一個完整的軟件系統(tǒng)的所有軟件部件的排列。在軟件工程過程中產(chǎn)生的組成一個系統(tǒng)某版本的所有的信息項（配置項）構(gòu)成了該系統(tǒng)版本軟件配置。軟件配置是一個動態(tài)的概念。隨著軟件過程的推進，配置項的數(shù)量在不斷增多，并隨時有變更而形成新的版本配置。1203。配置項（SCI）為了配置管理目的而作為一個單位來看待的軟件成份(軟部件)。軟件配置管理的對象就是軟件配置項或叫配置對象，它們是軟件工程過程中產(chǎn)生的信息項（文檔、報告、程序、表格、數(shù)據(jù)）121基本配置項和復(fù)合配置項（1）基本配置項（配置對象）是在軟件過程中通過分析、設(shè)計、編碼、測試所產(chǎn)生的“文本單元”，是配置管理中不再分割的軟件成份（軟部件）。極端情況下，可以把文檔中的一節(jié)或測試中的一個測試用例等定為一個SCI，通常的做法是把一個文檔、一整個測試用例組。一個命名的源程序，測試中一個等價類的測試用例看成一個SCI。122基本配置項和復(fù)合配置項（2）標識的配置項利用面向?qū)ο蟮姆椒ńM織起來。這種標識的對象分為：基本對象和復(fù)合對象復(fù)合配置項（配置對象）是基本對象或其它復(fù)合對象的聚集。例如把《設(shè)計規(guī)格說明書》看成是一個復(fù)合對象則它是由“數(shù)據(jù)設(shè)計”、“體系結(jié)構(gòu)設(shè)計”、“模塊設(shè)計”、“界面設(shè)計”等各章節(jié)作為基本對象的聚集。1234。配置標識配置標識是一組信息，它應(yīng)能唯一地標識一個配置項。為了方便對軟件配置項進行控制和管理，不致造成混亂，要用一組信息來唯一地標識每一個配置項，這一組信息就叫配置標識。對軟件系統(tǒng)(版本)的配置是通過配置標識實現(xiàn)的124如何定義配置標識配置項標識是一個字符串，它的基本內(nèi)容包括：配置項名字、配置項屬性描述、實現(xiàn)。名字：是一個字符串，例如“數(shù)據(jù)設(shè)計”、“體系結(jié)構(gòu)設(shè)計”、“……”、“設(shè)計說明”、程序模塊名。描述：配置項的類型（如文檔、程序、數(shù)據(jù)、測試用例、工具），項目標識，變更／版本信息。實現(xiàn)：該配置項指向父/子配置項的指針。125文檔配置標識實例RDV-BILL-WSite-HLD-003v2.0ProductProjectComponentDeliverableTypeDeliverableNumberVersion:Ele:YIBO-R&D-PROC-SCM-003v2.0

xamp1265.里程碑（Milestone),基線（Baseline）在軟件生存期各開發(fā)階段末尾的提交時間叫做里程碑（Milestone），是一個階段結(jié)束，下階段開始的時間點。在某些里程碑通過正式評審批準的軟件配置的正式文本成為基線?；€是某里程碑時新產(chǎn)生的配置項。基線的作用是把各階段工作劃分更加明確，以便于檢驗和肯定階段成果，是后面各軟件開發(fā)階段的依據(jù)（出發(fā)點），所以叫做基線。127基線以下軟件配置項可以是軟件配置管理的對象并可形成基線。系統(tǒng)規(guī)格說明軟件項目實施計劃軟件需求說明設(shè)計規(guī)格說明（數(shù)據(jù)設(shè)計、體系結(jié)構(gòu)設(shè)計、模塊設(shè)計、接口設(shè)計、對象描述——使用面向?qū)ο蠹夹g(shù)時）可執(zhí)行的或“書面”的原型初步的用戶手冊128文檔編制的起始與完成時間表文階段件可行性研究與計劃階段需求分析階段設(shè)計階段實現(xiàn)階段測試階段運行與維護階段可行性研究報告項目開發(fā)計劃軟件需求說明書數(shù)據(jù)要求說明書測試計劃概要設(shè)計說明書詳細設(shè)計說明書數(shù)據(jù)庫設(shè)計說明書模塊開發(fā)卷宗用戶手冊操作手冊測試分析報告開發(fā)進度月報項目開發(fā)總結(jié)129各階段的基線及配置項對應(yīng)需求分析客戶需求說明書軟件功能需求說明書據(jù)需求說明書工作陳述軟件項目計劃配置管理計劃質(zhì)量保證計劃驗收測試計劃系統(tǒng)測試計劃系統(tǒng)測試用例說明書概要設(shè)計Req基線總體概要設(shè)計說明書模塊概要設(shè)計說明集成測試計劃集成測試用例說明書詳細設(shè)計各模塊詳細設(shè)計說明各模塊測試用例說明編碼&UT測試發(fā)布各模塊編碼及單元測試報告項目中層匯總邏輯集成測試分析報告系統(tǒng)測試分析報告系統(tǒng)安裝手冊系統(tǒng)維護手冊Test基線用戶使用說明書項程序源代碼項驗收測試報告項目開發(fā)總結(jié)報告HLD基線DD基線Code基線Test基線Release基線變更1306.版本控制版本控制是利用工具來管理在軟件工程過程中產(chǎn)生的配置對象由于多次修改和變更所建立的不同版本。配置管理實施的版本控制使用用戶或開發(fā)者選擇適當?shù)陌姹緛泶_定軟件系統(tǒng)的配置。如果該圖是一個軟件系統(tǒng)的版本演變圖，則每個結(jié)點都是聚合對象給出該軟件系統(tǒng)的某個版本的軟件配置。131版本控制（續(xù)）下圖是一個配置對象版本的演變圖示例。對于每個配置對象都可以建立類似的演變圖。版本1.0版本1.1版本1.2版本1.3版本1.4版本2.0版本2.1版本1.1.1版本1.1.2132版本號示例版本編號約定:增量為0.1：小變更或bug修復(fù)第一個版本：V1.0增量為1.0：新的發(fā)布（增加若干功能）變體例：某軟件的一個版本由5個組件構(gòu)成，其中：

組件4適用于彩色顯示器

組件5適用于單色顯示器

則它的兩個版本，或稱兩個變體是

Version1:組件1，2，3，4

Version2:組件1，2，3，5123451337.變更控制軟件工程過程中對變更加以嚴格的控制和管理，以免發(fā)生混亂。變更控制過程：提出變更請求評估變更請求實施變更復(fù)審變更建立軟件新版本134三。軟件配置管理的主要活動1。計劃配置管理活動2。選擇配置管理工具3。建配置管理庫4。執(zhí)行配置控制5。識別配置；6。變更控制7。狀態(tài)記錄和報告8。審計2023/1/131351。計劃配置管理活動（1）軟件配置管理計劃應(yīng)是軟件開發(fā)計劃的一個組成部分。應(yīng)包括以下重要內(nèi)容：管理組織和責(zé)任、規(guī)程、工具、技術(shù)和方法計劃應(yīng)描述如何且何時執(zhí)行這些規(guī)程在此計劃發(fā)布之前要進行如下過程:確認和驗證過程文檔開發(fā)2023/1/13136計劃配置管理活動（2）軟件配置管理計劃還應(yīng)包括：規(guī)定項目基線、制定配置項標識編排規(guī)則，規(guī)則應(yīng)能反映配置項的結(jié)構(gòu)以便于追蹤，使標識具有唯一性（不允許多個配置項重名）和可追溯性（即標識能夠反映各配置項之間的相互關(guān)系，可追溯到相關(guān)的配置項）。2023/1/13137計劃配置管理活動（3）軟件配置管理計劃應(yīng)至少計劃建立三個基線它們是：功能基線：項目系統(tǒng)分析、設(shè)計完成后分配基線;軟件需求分析完成后產(chǎn)品基線:軟件系統(tǒng)測試完成后這三個里程碑的基線必須入受控庫,其他里程碑的產(chǎn)品是否作為基線可酌情處理?；€不宜建立過早、過多。例如,從詳細設(shè)計至確認測試前不宜設(shè)基線.2023/1/13138功能基線功能基線：是指在系統(tǒng)分析與軟件定義階段結(jié)束時，經(jīng)過正式評審和批準的系統(tǒng)設(shè)計規(guī)格說明書中對待開發(fā)軟件系統(tǒng)的規(guī)格說明；或是指經(jīng)過項目委托單位和項目承辦單位雙方簽字同意的協(xié)議書或合同中所規(guī)定的對待開發(fā)軟件系統(tǒng)的規(guī)格說明；或是指由下級申請經(jīng)上級同意或直接由上級下達的項目任務(wù)書中所規(guī)定的對待開發(fā)軟件系統(tǒng)的規(guī)格說明。功能基線是最初批準的功能配置標識。139指派基線指派基線：是指在軟件需求分析階段結(jié)束時，經(jīng)過正式評審和批準的軟件需求的規(guī)格說明。指派基線是最初批準的指派配置標識。140產(chǎn)品基線產(chǎn)品基線：是指在軟件組裝與系統(tǒng)測試階段結(jié)束時，經(jīng)過正式評審和批準的有關(guān)所開發(fā)的軟件產(chǎn)品的全部配置項的規(guī)格說明。產(chǎn)品基線是最初批準的產(chǎn)品配置標識。1412.選擇軟件配置管理工具為做好配置管理工作，尋求工具的支持是十分有益的，它可促進軟件配置管理工作提高效率。需要注意的是選擇時應(yīng)認真考察其適用性。工具名廠商CCC/Harvest

ChangeMan

ClearCase

Continuus

Endevor/MVS

PCVS

PCVSDimensions

Razor

SourceIntegrity

SourceSafe

TeamConnection

TUREchangePlatinumTechnology

SERENAInternational

Rational

Continuus

ComputerAssociates

INTERSOLV

INTERSOLV

TowerConcepts

MKS

MS

IBM

TRUEsoftware142軟件配置管理工具的主要功能配置支持；版本控制變化控制；Build支持；（配置項用于形成基線）過程支持；團隊支持；報告/查詢；審計控制。2023/1/131433。建立三類配置管理庫開發(fā)庫(DevelopmentLibrary)是指在軟件生存周期的某一個階段期間，存放與該階段軟件開發(fā)工作有關(guān)的計算機可讀信息和人工可讀信息的庫。專供開發(fā)人員使用，其中的信息會頻繁修改，對其控制相當寬松。144建立三類配置管理庫受控庫(ControlledLibrary)在生存期某一階段的工作結(jié)束時，存放階段產(chǎn)品而釋放的、與軟件開發(fā)工作有關(guān)的計算機可讀信息和人工可讀信息。軟件配置管理就是對受控庫中的各個軟件項進行管理，也稱軟件配置管理庫。145建立三類配置管理庫產(chǎn)品庫(ProductLibrary)在被開發(fā)的軟件產(chǎn)品完成系統(tǒng)測試后，存放最終產(chǎn)品等待交付用戶運行或現(xiàn)場安裝的軟件庫。1465。執(zhí)行配置控制跟蹤受控產(chǎn)品的變更來確保在所有時間都了解產(chǎn)品的配置。建立每個基線，跟蹤所有已建立的基線發(fā)生的的變更。所有基線配置項都應(yīng)遵循變更管理規(guī)范。每個基線配置變更狀態(tài)的歷史在整個生命周期過程中都應(yīng)受到維護以便進行狀態(tài)統(tǒng)計。對受控項的更改應(yīng)由授權(quán)的人的批準。建立正式的軟件配置控制委員會（SCCB）。147SCCB成分項目經(jīng)理關(guān)鍵的軟件開發(fā)工程師關(guān)鍵的軟件測試工程師SQA代表SCM代表148SCCB責(zé)任批準軟件基線和配置項的確定代表項目經(jīng)理和所有受軟件基線修改影響的組的利益評審和批準基線的變更批準從軟件基線庫中創(chuàng)建產(chǎn)品受影響組的例子有：硬件質(zhì)量保證，硬件配置管理，硬件工程，制造工程，軟件工程（包括所有下屬組，如軟件設(shè)計），系統(tǒng)工程，系統(tǒng)測試，軟件質(zhì)量保證，軟件配置管理合同管理，及文檔支持。149配置控制委員會的活動對差異報告和變更請求報告作出評價。對以下問題作決定：（1）變更的規(guī)模（2）相關(guān)系統(tǒng)的影響（3）變更要求的日期（4）對當前及后續(xù)工作的影響（5）成本150配置控制委員會的活動（6）涉及的范圍的危險程度（7）處理中已批準的變更（8）測試需求（9）資源(skills,