第五章軟件過程的項目管理5.1軟件配置管理開發人員在一種無法控制的狀態下訪問源代碼修改過的錯誤再次出現產品升級和維護所必需的程序和文檔非常混亂多項目、多版本的管理與開發同步和并行開發問題人員流動引起知識資產的流失項目開發狀態不清楚軟件生產達不到規模化集成過程拖延了產品投放市場的時間由于管理不善致使未經測試的軟件加入到產品中5.1軟件配置管理軟件項目開發管理的新需求你在一家小公司做軟件工程師，開始的時候，你只有一個人，配了2個助手。你們研究了一種算法（例如：圖象壓縮、數據加密等），編寫了一個實現模塊。有一天老板看到了你的演示，認為很有市場潛力，可以結合進公司正在給某行業用戶正在準備開發的系統中，成為該系統的核心技術或一個別人沒有的賣點。下一周，你的隊伍增加到14，與你3個人的小組不同的是，公司從其他部門為你配備了系統分析師，還有文檔編制員、測試員。你的核心模塊已經被大量的用戶功能所包裝，成為一個行業應用系統，并開始給用戶試用，這是你的系統的第一版。

3個月后，公司決定把系統升級到第二版，除增加了許多新的功能外，公司決定支持多平臺，同時，為了提高系統的性能和效率，準備采用第三方廠家的中間件，取代自己做的接口。第一版的缺陷修改，也要反映到第二版中。軟件項目開發管理的新需求第2版經過2個多月的開發，最終推向了市場。公司的這個產品不但被用戶所歡迎，也被一家大公司所看中，你們的產品，正好可以填補這家大公司產品線的空缺，你所在的公司被這家公司買去了。公司為你的項目組派來了產品經理、項目經理。公司決定這個產品的測試，由公司總部獨立的測試部門承擔。同時，公司決定把項目組增加到50人，其中有20多人并不在你所在的城市。在新公司里，產品管理、項目管理、測試、質量等等，都與你過去的環境和做法不同，特別不同的是，公司準備開發的第3版系統與公司原有的產品要進行融合，使他們看上去是一家出來的不同的兄弟和姐妹。5.1軟件配置管理沒有配置管理有配置管理5.1軟件配置管理5.1軟件配置管理軟件配置的定義軟件配置是由在軟件工程過程中產生的所有信息項構成的，它可以看作該軟件的具體形態（軟件配置項）在某一時刻的瞬間影像。軟件配置管理中的基本概念配置配置是在技術文檔中明確說明最終組成軟件產品的功能或物理屬性。配置項在軟件生存周期內所產生的各種應納入管理范圍的系統構成成分。包括各種管理文檔和技術文檔，源程序與目標代碼，以及運行所需的各種數據等（配置管理的資源對象）。基線基線是評審過的一個或多個軟件配置項，每一個基線都是下一步開發的出發點和基礎。軟件配置管理中的基本概念版本表示一個配置項具有一組定義的功能的一種標識。隨著功能的增加、修改或刪除，配置項被賦予不同的版本號。一般在配置標識方案中給出版本標識方法。軟件配置管理中的基本概念配置管理庫配置管理庫也稱受控庫，用于存儲軟件配置項以及相關配置管理信息。5.1軟件配置管理軟件配置管理（SoftwareConfigurationManagement，SCM）對軟件開發組所建立的軟件的修改進行標識、組織和控制的藝術，其目標是減少錯誤，提高生產力；能夠系統地處理變更，從而使得軟件系統可以隨時保持其完整性，又可稱為變更控制，可以用來評估提出的變更請求，跟蹤變更，并保存系統在不同時間的狀態；5.1軟件配置管理“軟件配置管理過程是在整個軟件生存期中實施管理和技術規程的過程，它標識、定義系統中的軟件項并指定基線；控制軟件項的修改和發行；記錄和報告軟件項的狀態和修改申請；保證軟件項的完整性、協調性和正確性以及控制軟件的存儲、處理和交付。”------ISO/IEC12207軟件配置管理的功能并行開發支持；修訂版本管理；版本控制；產品發布管理；建立管理；過程控制；變更請求管理；代碼共享。軟件配置管理流程基線控制

計劃基線需求基線設計基線

編碼基線測試基線版本控制1.版本的訪問和同步控制Check-in和Check-out軟件配置項通過檢入(Check-in)，進入配置庫，開始“凍結”；由于各種原因需要變更，從配置庫中檢出（Check-out）配置項；checkin和checkout通過加鎖協調多用戶操作；每次checkin時，在配置庫上都會生成新的版本。版本控制2.版本的分支版本控制3.版本的合并將需要保護的分支鎖定，打上Release標簽。在以Release標簽為基線的分支上開發1.1版本。版本合并：1.1版本開發完成，希望合并到基線版本中作為以后開發新版本的基礎。變更控制微軟的每日編譯每日編譯每天都對所有的源代碼進行一次完整的編譯，生成一份可執行的產品程序；每日編譯的目的展示最新進展測試的基礎產生新版本號檢查并發布編譯結果生成編譯報告5.2軟件風險管理軟件開發的風險用戶要求是否能確切地被理解？在項目最后結束之前要求實現的功能能否建立？是否存在目前仍未發現的技術難題？在項目出現嚴重誤期時是否發生一些變更？糟糕的計劃與估算人員流動……軟件風險的類型項目風險：威脅到項目計劃進度、人力、資源、客戶及需求等問題技術風險：威脅到軟件的質量及交付時間設計、實現、接口、驗證和維護等問題商業風險：威脅到軟件的生存能力市場風險策略風險銷售風險管理風險預算風險5.2軟件風險管理軟件風險管理對影響軟件項目、過程或產品的風險進行評估和控制的實踐過程。軟件風險管理是管理和開發軟件系統必不可少的要素軟件風險是工作與生俱來的；軟件風險隨著系統復雜程度的增加而增加；軟件風險阻礙人們實現目標。風險事件圖高低生命周期風險發生的概率處理風險事件的成本風險管理成熟度模型問題階段緩和階段防范階段預知階段機會階段我疲于救火！我想知道哪里會出錯！我想采取行動不留遺憾！我想知道成功的機會有多大！我想超過期望！常用的風險識別方法檢查單文件審核頭腦風暴德爾菲法訪談SWOT分析圖表分析No.軟件風險相應對策1人員不足錄用優秀人才；人員應適應崗位需要；全面考慮團隊建設；骨干人員工作要協調；實施培訓；預先安排關鍵人員的使用計劃2進度計劃和預算不準確詳細評估多種資源成本和進度；依成本進行設計；采用漸增式開發；軟件復用；純凈需求3開發了錯誤的軟件功能進行組織分析；實施任務分析；進行用戶調查；開發原型；及早編制用戶手冊4開發了不適用的用戶接口開發原型；制作腳本；作業分析；弄清了用戶特征(功能性、風格、工作負荷)5只追求表面效果，需求中含有一些不必要的功能（鍍金）純凈需求；開發原型；成本－效益分析；依成本進行設計6需求不斷變更重大變更設限；信息隱蔽；漸進式開發7外供部件不足制定基準點；檢驗；參考基準檢查；兼容性分析8外包任務問題參考基準檢查；發包前審核；未發包合同；競標設計或開發原型；建立團隊9實時性能達不到要求模擬；制定基準；建模；開發原型；安裝測量裝置；調準10誤解計算機科學能力技術分析；成本－效益分析；開發原型；參考基準檢查10種常見的軟件風險定量的風險分析量化的風險分析通常需要對事實進行更詳細的分析，較之主觀的風險分析往往更為可靠。主要的量化分析方法有：

比率/范圍分析概率分析敏感性分析定量的風險分析可能性定義為百分數、一個詞組或一個相對數字定量的風險分析影響度從性能、成本、進度和支持四個風險因素分析影響度。5.3項目計劃管理什么：工作的具體內容，一定時期的工作重點怎樣：如何完成這些工作和任務誰：確定具體人員或部門何時：各項工作需要多少時間多少：每項工作需要多少經費哪里：各項工作進行的環境常見錯誤過于樂觀的計劃在壓力下放棄計劃在項目過程中不細化計劃、不及時更新計劃，不監控計劃的執行缺乏足夠的風險管理缺乏質量計劃項目估算時遺漏必要的任務前期活動不合要求項目計劃的重要性體現了對客戶需求的理解為項目管理和運作提供可行的計劃是有條不紊地開展軟件項目活動的基礎跟蹤、監督和評審計劃執行情況的依據是項目相關個人和組織的明確承諾項目計劃工作分解結構表（WBS）工作分解結構（WBS，WorkBreakdownStructure）以工作為導向對項目要素進行的分組，它定義了項目的整個工作范圍，每細分一層表示對項目工件更詳細的描述。工件（Artifact）指軟件開發過程的中間或最后工作產品，包括文檔、模型和程序。WBS-工作分解結構1項目范圍規劃

1.1 確定項目范圍

1.2 獲得項目所需資金

1.3 定義預備資源

1.4 獲得核心資源

1.5 項目范圍規劃完成2分析/軟件需求

2.1 行為需求分析

2.2 起草初步的軟件規范

2.3 制定初步預算

2.4 工作組共同審閱軟件規范/預算

2.5 根據反饋修改軟件規范

2.6 確定交付期限

2.7 獲得開展后續工作的批準(概念、期限和預算)2.8 獲得所需資源

2.9 分析工作完成3設計

3.1 審閱初步的軟件規范

3.2 制定功能規范

3.3 根據功能規范開發原型

3.4 審閱功能規范

3.5 根據反饋修改功能規范

3.6 獲得開展后續工作的批準

3.7 設計工作完成4開發

4.1 審閱功能規范

4.2 確定模塊化/分層設計參數

4.3 分派任務給開發人員

4.4 編寫代碼

4.5 開發人員測試(初步調試)4.6 開發工作完畢……創建WBS的基本法則每個工作工作單元在WBS只能出現一次概要任務是對其下所有任務的總結每個WBS的條目都有單獨的人員負責與實際要做的工作情形保持一致建立WBS時應讓項目組員參予每個WBS條目都應備案WBS既要靈活又要不失控制任務安排建立網絡圖，確定關鍵路徑。根據每個活動的工期估算值設置時間窗口前向路徑(forwardpass)計算各個活動的最早結束時間反向路徑(backwardpass)計算各個活動的最晚開始時間節假日等非工作日除外考慮時間緩沖，按工期的百分比或固定時間。對活動時序關系設定Lead和Lag。示例示例：前向路徑計算示例：后向路徑計算關鍵路徑識別Slack為0的事件為關鍵事件，將關鍵事件連接起來的最長路徑為關鍵路徑活動的浮動時間具有slack事件的活動具有浮動時間。總浮動是活動的最早結束時間和最遲結束時間的差。項目網絡圖PERT計劃評審技術、CPM關鍵路徑法，采用網絡圖來描述項目的進度安排。023456718起點A編碼A調試B編碼A測試C理解Ｂ測試C修改C調試C測試6687887968BC組裝測試5Ｂ調試任務網絡圖練習以嵌入式USB主機為例，建立工作分解結構，利用網絡圖技術分析項目的關鍵路徑，合理分配嵌入式USB主機項目的設計開發時間，控制進度。1.創建工作分解結構WBS；2.制定項目活動表；3.繪制前導圖；4.前向路徑計算；5.后向路徑計算；6.確定關鍵活動及路徑。創建WBS制定項目活動表活動活動內容持續時間（周）先行活動A項目需求分析2\B系統總體設計2AC系統硬件設計3BD初始化及用戶交互界面軟件設計3CE單片機與接口芯片通信軟件設計3DFUSB主機系統軟件設計5EGMS設備類協議軟件設計3DHFAT文件系統軟件設計3CI系統聯調測試2F、G、HJ項目結題報告1I時間安排-甘特圖甘特圖：用水平線段表示任務的工作階段；線段的起點和終點分別表示任務的開始和完成時間，線段的長度表示完成任務所需的時間。1234567891011

任務ABCDE當前進度○△○△○△○△○△完成計劃完成○文檔編寫

△評審圖例項目計劃案例：建造地牢說明：你是路易10世的俘虜。他要給自己的城堡增加三個新地牢，讓你做一個規劃。干得好就釋放，干不好就終生監禁。小地牢很難設計，要12周，但容易建成，1周即可；中地牢設計要5周，施工要6周；大地牢設計只要1周，但建造要用9周。你有一個設計師和一個建筑師，設計師不會建造而建筑師不會設計。要建好這三個地牢，你規劃的工期是幾周？不同的思路設計建造地牢設計建造小地牢中地牢大地牢小地牢中地牢大地牢設計建造地牢設計建