軟件項目管理章

1、1. 課堂授課2. 案例講解3. 專題講座4. 課程實踐 Microsoft Visual SourceSafe (VSS)。微軟Windows平臺下的一個小型軟件配置管理工具。 Microsoft Project。微軟Windows平臺下國際通用的項目管理軟件。1.PANKAJ JALOTE, CMM in Practice: Processes for Executing Software Projects at Infosys, 高等教育出版社, 2000. 1.M.C. Paulk, Capability Maturity Model for Software, SEI-91-TR-2

2、4, 1991.2.Pankaj Jalote, Software Project Management in Practice, 2002. p你是否參加過軟件項目的開發(fā)?p你是否組織過軟件項目的開發(fā)?p有哪些印象深刻的成功和失敗案例?p你認為軟件開發(fā)中最具挑戰(zhàn)性的問題是什么?p你認為自己能否勝任以下職位 程序員、設計師、項目經(jīng)理、開發(fā)顧問p你希望將來在IT企業(yè)中充當什么角色？如何達成？1.1. 軟件開發(fā)與軟件項目管理1.2. CMM簡介1.3. INFOSYS公司的項目管理實踐1. 軟件項目管理的重要性2. 軟件危機的提出3. 世界軟件產(chǎn)業(yè)發(fā)展現(xiàn)狀及中國軟件業(yè)的差距 p 為何需要軟件項目管

3、理？ 軟件的定義： 是使計算機能夠工作的指令集合和相應的數(shù)據(jù)結構和文檔，是一種產(chǎn)品，將計算機的硬件能力發(fā)揮出來的一種工具，是傳遞信息的一種工具，對信息的處理手段。 p 軟件的特征：1. 軟件是一種邏輯元素，而不是物理元素；2. 軟件是開發(fā)出來的，而不是用傳統(tǒng)的方法制造出來的；3. 軟件不會被用壞，一般產(chǎn)品的失敗概率都遵循浴盆曲線；4. 工業(yè)界已經(jīng)是標準化裝配時代，但軟件還是定制時代；5. 創(chuàng)新性和人為因素更高。 p 軟件開發(fā)是一個高風險的過程p 軟件過程的管理是軟件成功的關鍵p 職業(yè)的發(fā)展方向、軟件企業(yè)的生存的重要性p “軟件危機” 的主要原因 用戶不易準確描述對軟件的需求，經(jīng)常存在二義性，遺

4、漏甚至錯誤 p “軟件危機” 的主要原因 大型軟件往往需要成百上千人的合作，由于軟件系統(tǒng)結構復雜，如何有效組織管理、充分發(fā)揮團隊作用就成為軟件開發(fā)成功的關鍵。 個人 VS 團隊計算機軟件和硬件費用比 60 70 80 90p “軟件危機” 的主要原因 缺乏有效的軟件開發(fā)方法和工具的支持，過分依靠程序設計在開發(fā)中的技巧和創(chuàng)造性，加劇了軟件產(chǎn)品的個性化。開發(fā)過程沒有統(tǒng)一、規(guī)范的方法論指導，文檔資料不齊全。 p “軟件危機” 的主要原因 缺乏軟件開發(fā)經(jīng)驗及相關數(shù)據(jù)積累，無法準確估計經(jīng)費和進度，導致經(jīng)費嚴重超支，完成期限一拖再拖。 忽視測試階段的工作，提交的產(chǎn)品質量差。 1999,10月，美國NASA

5、火箭氣象衛(wèi)星失蹤，耗資1.25億美元。軟件的錯誤，英制和公制的轉換問題導致。 1963-1966 美國IBM360機器的操作系統(tǒng)，5000人年的工作量，1000多人進行開發(fā)，100萬行代碼，新版本是在老版本中找出1000個以上的錯誤之后修正開發(fā)。當時的情況很不好，主要負責人Brooks 把他們當時比作陷在泥潭的困獸，越掙扎越深。-人月神話 1999年8月，在美國的一個大型的商業(yè)高速數(shù)據(jù)網(wǎng)絡里，軟件的缺陷影響了7000多個商業(yè)用戶，時間長達8天。 1998年4月，美國的一個重要數(shù)據(jù)通訊網(wǎng)絡出現(xiàn)24小時的故障，使大部分美國的信用卡業(yè)務受到影響。受影響的還有美國的一些大銀行、零售商和政府的數(shù)據(jù)系統(tǒng)。

6、也是軟件故障。 1997年8月，美國一家最主要的信用卡報告公司的新網(wǎng)站開啟2天就關閉了，主要是查詢自己的信用卡使用情況，但看到的是別人的賬單，而不是自己的。 邏輯產(chǎn)品，不同于物理產(chǎn)品復雜性高 邏輯產(chǎn)品，邏輯復雜性，遠高于硬件復雜性 軟件的復雜性隨規(guī)模呈指數(shù)級上升規(guī)模大 應用擴大，代碼量仍在不斷膨脹影響軟件生產(chǎn)率和質量的因素比較復雜 人員的能力和水平 團隊合作缺乏有效、系統(tǒng)原理、原則、方法和工具的指導和輔助美國印度愛爾蘭軟件產(chǎn)值的比較（軟件產(chǎn)值：億）印度中國199953.267.5200071.788.5200196.3102.32002110124“2009年，我國軟件收入去年已經(jīng)達到人民幣7

7、573億元，印度700到800億美元，算下來相當于人民幣6000億左右，從這個角度說中國已經(jīng)超越印度?！?陳沖，中國軟件行業(yè)協(xié)會理事長軟件出口的比較（軟件產(chǎn)值：億）印度中國1999392.52000624200177.87.2中國占世界軟件外包行業(yè)的比重（軟件產(chǎn)值：億美元）世界軟件外包規(guī)模中國20043348.3200541410.9200651914.5200764219.9200878127.82009943392006年軟件外包份額印度34.2愛爾蘭29.2菲律賓2.9中國2.4世界軟件外包介紹1.1. 軟件開發(fā)與軟件項目管理1.2. CMM簡介1.3. INFOSYS公司的項目管理實踐

8、1. CMM簡介2. CMM的成熟度級別3. 不同級別的KPA 4. CMM 的評估方法 CMM Capability Maturity Model for Software. 軟件能力成熟度模型是一種描述有效軟件過程的關鍵元素的框架，CMM描述一條從無序的不成熟的過程到成熟的、有紀律的過程的進化的改進途徑。 CMM包括對軟件開發(fā)和維護進行策劃、工程化和管理的實踐。遵循這些關鍵實踐，就能改進組織在實現(xiàn)有關成本、進度、功能和產(chǎn)品質量等目標上的能力。 CMM的起源與發(fā)展 CMM的起源: 軟件危機1986，SEI（CMU的軟件的軟件工程研究所）正式著手這工程研究所）正式著手這項工作項工作1987年年

9、9月，月， 發(fā)布發(fā)布“能力成能力成熟度框架熟度框架”和和“成熟度問卷成熟度問卷”1991，CMM1.01993，CMM1.1CMM-Ip 1999年7月6日，由IBM和清華同方合資成立的北京鼎新信息系統(tǒng)開發(fā)有限公司，在國內(nèi)首次通過CMM2級。p 2000年左右，全球60多家CMM5級的企業(yè)，印度占了40個。國內(nèi)當時通過CMM5級的企業(yè)，有摩托羅拉中國研究院，華為印度研究院，2007年東大阿爾派（東軟前身）。p 一般，外包企業(yè)比較適用于通過CMM評估，而以創(chuàng)造性為主的軟件公司，例如微軟、IBM、Google等，均沒有進行CMM評估。p 大連海輝、華信都通過CMM5，主要做軟件外包。我國的CMM發(fā)

10、展情況： 軟件過程 軟件過程能力 軟件過程性能 軟件過程成熟度 軟件過程 人們用于開發(fā)和維護軟件及其相關過程的一系列活動，包括軟件工程活動和軟件管理活動。 軟件過程能力 描述（開發(fā)組織或項目組）遵循其軟件過程能夠實現(xiàn)預期結果的程度，它既可對整個軟件開發(fā)組織而言，也可對一個軟件項目而言。 軟件過程性能 表示（開發(fā)組織或項目組）遵循其軟件過程所得到的實際結果，軟件過程性能描述的是已得到的實際結果，而軟件過程能力則描述的是最可能的預期結果，它既可對整個軟件開發(fā)組織而言，也可對一個特定項目而言。 1. 成熟度的五個級別2. 成熟度等級的五個級別的主要特征3. 軟件過程的可視性 4. 過程能力和性能預測

11、 CMM的成熟度級別 1級 初始級 (Initial) 2級 可重復級 (Repeatable) 3級 已定義級 (Defined) 4級 已管理級 (Managed) 5級 優(yōu)化級 (Optimizing)成熟度等級1-5： CMM的成熟度級別 初始級特征：軟件過程的特點是無秩序的，偶爾甚至是混亂的，幾乎沒有什么過程是經(jīng)過定義的，成功依賴于個人努力。 可重復級特征：已建立基本的項目管理過程去跟蹤成本進度和功能，必要的過程紀律已經(jīng)就位，使具有類似應用的項目能重復以前的成功。 成熟度等級的五個級別的主要特征 CMM的成熟度級別 已定義級特征：管理活動和工程活動兩方面的軟件過程均已文檔化、標準化，

12、并集成到組織的標準軟件過程中，全部項目均采用供開發(fā)和維護軟件用的組織標準軟件過程的一個經(jīng)批準的普及剪裁版本。 已管理級特征：已采集詳細的有關軟件過程和產(chǎn)品質量的度量，無論軟件過程還是產(chǎn)品均得到定量了解和控制。 優(yōu)化級特征：利用來自過程和來自新思想、新技術的先導性實驗的定量反饋信息，使持續(xù)過程的改進成為可能。 成熟度等級的五個級別的主要特征 CMM的成熟度級別軟件過程的可視性： 等級1 一個黑盒 等級2 項目里程碑處具有管理可視性 等級3 盒子的內(nèi)部結構可視 等級4 軟件過程被配備上度量，并得到定量地控制 等級5 對過程不斷改進 CMM的成熟度級別過程能力和性能預測 隨著成熟度增長，實際結果相對

13、預定目標結果的偏差范圍減小 隨著成熟度增加，預定目標結果得到改善 CMM的成熟度級別什么是關鍵過程區(qū)域（Key Process Area，KPA）？每個關鍵過程區(qū)域識別出一串相關活動，當這些活動全部完成時，能達到一組對增強過程能力至關重要的目標 。KPA的特性：p 每個KPA識別出一串相關活動p 每KPA定義在單個成熟度等級上p KPA鑒別出為達到某一成熟度等級所必須解決的問題 不同級別的KPAKPA的結構：p 目標p 共同特點 執(zhí)行約定 執(zhí)行能力 執(zhí)行活動 測量和分析 驗證實施 不同級別的KPAKPA的目標（Goal）：p 目標概括一個KAP中的所有關鍵實踐，并能用于確定一個組織或項目是否已

14、有效地實施此KPA。p 目標表示每個關鍵過程域地范圍、邊界和意圖。 不同級別的KPAKPA的共同特點：p 執(zhí)行約定(Commitment to Perform) ：企業(yè)為了建立和實施相應KPA所必須采取的行動；p 執(zhí)行能力(Ability to Perform) ：描述了為了某軟件過程得以始終如一地執(zhí)行必須在項目或企業(yè)中存在的先決條件，是企業(yè)實施KPA的前提條件；p 執(zhí)行活動(Activities Performed) ：描述了執(zhí)行KPA所需求的必要行動、任務和步驟；其是唯一一項與項目執(zhí)行相關的屬性。p 度量和分析(Measurement and Analysis) ：關注于這個關鍵過程域的活

15、動需要做的度量和度量分析要求。p 驗證實施(Verifying Implementation) ：是驗證執(zhí)行活動是否與建立的過程一致，核實以確保所實施的過程是按照原定的計劃以及達到其目標，著眼于保證過程的實現(xiàn)要通過獨立的個人和高級管理人員驗證。 不同級別的KPA執(zhí)行約定(Commitment to Perform) ：執(zhí)行約定是企業(yè)為了建立和實施相應KPA所必須采取的行動，這些行動主要牽涉到企業(yè)范圍的政策和高層管理的責任。 不同級別的KPA執(zhí)行能力(Ability to Perform) 執(zhí)行能力描述為了使某軟件過程得以始終如一地執(zhí)行的必須在項目或企業(yè)中存在的先決條件，是企業(yè)實施KPA的前提條

16、件。企業(yè)必須采取措施，在滿足了這些條件后，才有可能執(zhí)行KPA的實踐活動。 執(zhí)行能力關注于項目計劃的實踐；資源的配置；責任的布置與授權；以及各種有關的培訓等，這些都是為了執(zhí)行這個關鍵過程域的活動而對特定人以及作為整體的機構的能力開發(fā)起非常重要作用的事務。 不同級別的KPA執(zhí)行活動(Activities Performed) 執(zhí)行活動描述了執(zhí)行KPA所需求的必要行動、任務和步驟。 在五個公共屬性中，執(zhí)行活動是唯一與項目執(zhí)行相關的屬性，其余四個屬性則涉及企業(yè)CMM能力基礎設施的建立。 執(zhí)行活動一般包括計劃、執(zhí)行的任務、任務執(zhí)行的跟蹤等。 不同級別的KPA驗證實施(Verifying Implemen

17、tation) 驗證實施是驗證執(zhí)行活動是否與建立的過程一致，核實以確保所實施的過程是按照原定的計劃以及達到其目標，著眼于保證過程的實現(xiàn)要通過獨立的個人和高級管理人員驗證。涉及到管理的評審和審計以及質量保證活動，包括：過程執(zhí)行的確保，產(chǎn)品要求的確保，高層管理人員進行的審核和項目經(jīng)理進行的審核。 不同級別的KPA測量和分析（Measurement and Analysis）：測量和分析關注于這個關鍵過程域的活動需要作的度量和度量分析要求。典型的測量和分析的要求是確定執(zhí)行活動的狀態(tài)和執(zhí)行活動的有效性。 不同級別的KPA 不同級別的KPAp CMM共有18個KPA，其中： 2級 6個 3級 7個 4級

18、 2個 5級 3個等級2的KPA：p 需求管理 RM(Requirements Management)p 軟件項目策劃SPP(Software Project Planning)p 軟件項目跟蹤和監(jiān)督SPTO(Software Project Tracking and Oversight)p 子合同管理SSM (Software Subcontract Management)p 質量保證SQA(Software Quality Assurance)p 軟件配置管理SCM(Software Configuration Management) 不同級別的KPA等級3的KPA：p組織過程焦點OPF

19、(organization process focus)p組織過程定義OPD(organization process definition)p培訓大綱TP(training program)p集成軟件管理ISM (integrated software management )p軟件產(chǎn)品工程SPE(software product engineering)p組間協(xié)調(diào)IC(intergroup coordination)p同行評審PR( peer reviews) 不同級別的KPA等級4的KPA：p定量過程管理QPM (quantitative process management)p軟件質量

20、管理SQM (software quality management)等級5的KPA：p缺陷預防DP (defect prevention)p技術改革管理TCM(technology change management )p過程更改管理 PCM(process change management ) 不同級別的KPA1. 過程評估與過程評價2. 過程評估的方法 CMM的評估方法p 軟件過程評估：用于確定一個組織的當前軟件過程的狀態(tài)，確定組織所面臨的具有高優(yōu)先級的與軟件過程有關的問題，和獲得組織對軟件過程改進的支持。p 軟件過程評價：用于識別合格的能完成軟件工作的承包商或者監(jiān)控現(xiàn)有軟件工作中所應

21、用的軟件過程的狀態(tài)。 CMM的評估方法過程評估的方法：成熟度問卷文檔面談 CMM的評估方法1.1. 軟件開發(fā)與軟件項目管理1.2. CMM簡介1.3. INFOSYS公司的項目管理實踐1. INFOSYS公司的背景知識 2. SEPG對項目的支持3. 高層經(jīng)理參與項目4. 項目經(jīng)理培訓5. 項目管理過程(項目規(guī)劃, 項目執(zhí)行, 項目收尾)INFOSYS公司的項目管理實踐 Infosys技術有限公司是一家總部在印度班加羅爾的一家全球技術服務公司。這家公司在2011年財富印度500強中列第27名。Infosys在29個國家設有辦公室并在印度、美國、中國、澳大利亞、英國、加拿大、日本等地設有研發(fā)中心

22、。公司在超過30個國家提供商業(yè)咨詢、技術、工程及外包服務。 Infosys簡介 Software Engineering Process Group，軟件工程過程小組 工作開銷 SEPG VS. QA SEPG1. CEO 2. SEPG 3. 管理委員會 高層管理者介入p項目計劃階段p項目執(zhí)行階段p項目收尾階段 項目管理過程1. 項目管理的概念2. 項目管理的主要內(nèi)容3. 項目管理的階段劃分下面哪些活動是項目？q上課 q野餐活動q某次企業(yè)的校園宣講會q社區(qū)保安q開發(fā)某套管理軟件q每天的衛(wèi)生保潔 q玉兔登月計劃項目的定義 所謂項目，就是為創(chuàng)建某一獨特產(chǎn)品或服務，在一定的環(huán)境和約束條件下進行的臨

23、時性努力 即它是利用有限的資源，在有限的時間內(nèi)為特定客戶完成特定目標的一次性工作。項目的特征：1.一個明確的范圍和目標；2.一個預期的完成時間；3.有可以利用的資源；4.一種已定義的性能評估方法；5.不是例行的任務下面哪些活動是項目？q上課 q野餐活動q某次企業(yè)的校園宣講會q社區(qū)保安q開發(fā)某套管理軟件q每天的衛(wèi)生保潔 q玉兔登月計劃項目日?；顒邮裁词琼椖抗芾恚縫 Badiru(1991)將項目管理定義為：一種為高效恰當?shù)赝瓿赡硞€既定的目標而對資源進行管理、分配和調(diào)度的過程。 p 我們也可以把項目管理定義為：一種為實現(xiàn)既定目標而對技術、人力及金融資源所進行的系統(tǒng)集成。 質量管理時間管理 成本管理

24、 風險管理 人力資源管理 合同/采購管理范圍管理 通訊管理項目綜合管理項目管理的三要素：項目質量成本進度項目管理主要有三大階段p項目規(guī)劃p項目執(zhí)行p項目收尾 項目規(guī)劃： 主要是項目經(jīng)理審閱合同條款，并制定一個滿足他們的計劃，實際上包括：定義生命周期、估計工作量和進度、制定任務進度計劃等。 項目執(zhí)行： 包括執(zhí)行項目計劃、跟蹤項目的狀態(tài)，并在項目的績效偏離項目計劃設定的績效時采取措施進行糾正。 項目收尾： 主要是在客戶接收工作產(chǎn)品之后對項目進行系統(tǒng)的總結。數(shù)據(jù)分析是這一階段的主要任務。 1. 需求開發(fā)（分析和產(chǎn)生需求的過程，發(fā)生在軟件生命周期的開始）2. 需求管理 （包括對需求的評審、變更、跟蹤，

25、貫穿于整個軟件生命周期） 1. 需求2. 需求分析和需求規(guī)格3. 需求變更4. 需求跟蹤 什么是需求？IEEE軟件工程標準詞匯表（1997年）定義需求為：用戶解決問題或達到目標所需的條件或權能（Capability）。系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權能。一種反映上面 或 所描述的條件或權能的文檔說明。 需求分析的過程1) 準備階段：閱讀技術以及商務概念上的背景資料并進行培訓、熟悉客戶使用的方法和工具、確定信息的采集方法、準備好提問問題、確定用戶組與評審專家、計劃原型、確定需求規(guī)格標準、制定會談計劃；2) 采集、澄清需求：建立系統(tǒng)目標和范圍、采集功能需求、

26、采集外部接口信息、采集環(huán)境需求、采集性能需求、采集標準需求、采集用戶特殊需求、準備和評估原型；3) 分析需求：設計過程模型、設計邏輯數(shù)據(jù)模型、建立數(shù)據(jù)字典；4) 準備SRS（Software Requirements Specification, 需求規(guī)格說明書）5) 評審SRS6) 客戶認可并簽署SRS1. 需求規(guī)格說明書（需求規(guī)格說明書的要求）SRS的要求：正確性、無二義性、完整性、一致性、可測試性、可跟蹤性。 需求是會發(fā)生變化的，而且需求的變更可以在項目生命周期的任何時間發(fā)生。越是發(fā)生在后期，對項目的影響越大。如何管理好需求變更的申請是非常重要的。 需求變更管理過程：變更管理過程規(guī)定如何

27、發(fā)出變更申請、何時需要正式批準等。在出現(xiàn)需求變更申請時，必須執(zhí)行需求變更管理過程。 一般的變更管理過程 記錄變更 分析變更對工作產(chǎn)品的影響 估計變更申請所需的工作量 重新估計交付時間表 執(zhí)行累計的成本影響風險 如果影響超出一定的限度，則與高級主管一起評審影響 客戶不再提出變更申請 修改工作產(chǎn)品 跟蹤矩陣 跟蹤矩陣的維護和使用1. 軟件開發(fā)過程及描述2. 過程裁剪p 過程描述/定義 過程描述是項目可以用來遵照執(zhí)行某些任務的一系列步驟，以及執(zhí)行這些步驟的指南。開發(fā)過程是提煉用戶需求，設計、構建和測試滿足這些需求的軟件并最終將其交付給客戶所需的過程：需求分析概要設計詳細設計編碼單元測試集成測試系統(tǒng)測

28、試驗收測試每個開發(fā)子過程都包括：1.輸入準則2.輸入3.輸出準則4.輸出5.度量給出從計算機的邏輯角度開發(fā)針對用戶需求的解決方案。p 輸入準則：需求規(guī)格文檔經(jīng)過評審并授權p 輸入：需求規(guī)格文檔p 輸出準則：概要設計文檔經(jīng)過評審和授權p輸出：概要設計文檔、項目標準、概要設計評審記錄p 度量：工作量、缺陷p 主要步驟：p 進一步對概要設計中的整體應用分解，分解成模塊和程序，對程序進行邏輯設計。p 輸入準則：概要設計文檔經(jīng)過評審和授權p 輸入：概要設計文檔p 輸出準則：詳細設計文檔和單元測試計劃已經(jīng)經(jīng)過評審和授權p 輸出：詳細設計文檔和單元測試計劃p 度量：工作量、缺陷p 主要步驟：p 根據(jù)詳細設計

29、用編程語言編寫所需要的程序p 輸入準則：詳細設計文檔經(jīng)過評審并授權p 輸入：詳細設計文檔、項目標準、單元測試計劃、程序框架p 輸出準則：成功執(zhí)行所有單元測試計劃中的測試用例p 輸出：源代碼、可執(zhí)行代碼、測試數(shù)據(jù)p 度量：工作量、缺陷p 主要步驟：p 已通過單元測試的模塊構建成一個完整軟件結構的系統(tǒng)方法p 輸入準則：概要設計文檔經(jīng)過評審和授權p 輸入：概要設計文檔和程序p 輸出準則：成功執(zhí)行所有集成測試計劃中的測試用例p 輸出：源代碼、可執(zhí)行代碼、測試數(shù)據(jù)p 度量：工作量、缺陷p 主要步驟：p 依據(jù)需求規(guī)格驗證軟件產(chǎn)品有效性的活動；目的是為了發(fā)現(xiàn)那些只有通過測試整個系統(tǒng)才能暴露的缺陷p 輸入準則

30、：需求規(guī)格和概要設計文檔經(jīng)過評審和授權p 輸入：需求規(guī)格和概要設計文檔p 輸出準則：成功執(zhí)行所有集成測試計劃中的測試用例p 輸出：源代碼、可執(zhí)行代碼、測試數(shù)據(jù)p 度量：工作量、缺陷p 主要步驟：p 把軟件產(chǎn)品集成到它的操作環(huán)境中，并在這個環(huán)境中經(jīng)受測試，確保它按需求執(zhí)行。p 輸入準則：成功的完成系統(tǒng)測試p 輸入：測試后的軟件和驗收測試文檔p 輸出準則：客戶簽署驗收單p 輸出：安裝后的軟件p 度量：工作量和缺陷p 主要步驟：p主要是操作手冊，用戶手冊及客戶需要的其他文檔。p主要活動：p輸入準則：p輸入：p輸出準則：p輸出：p度量：p主要步驟：p 過程裁剪是調(diào)整組織標準過程的過程，以此來獲得用于項

31、目的特定業(yè)務或技術需要的過程。p 主要有： 概要裁剪指南 詳細裁剪指南p 提出基于某些項目特效，在項目中應該如何執(zhí)行一些通常的活動。p 概要級剪裁：根據(jù)項目特征，應用總體指南標準對標準過程進行剪裁，用到如下特征。（1）團隊和項目經(jīng)理的經(jīng)驗和熟練程度。（2）團隊人數(shù)最多時的人數(shù)。（3）需求透明度（4）項目持續(xù)時間（5）應用的關鍵程度列出過程中各種生命周期階段的所有活動，還包括對每個活動相應的裁剪活動,指定每個步驟是必要的還是可裁剪，并給出選擇的指南。1.軟件度量2.過程數(shù)據(jù)庫（Process Database, PDB）3.過程能力基線(Process Capability Baseline ,

32、 PCB)4.過程財富( Process Asset)p軟件度量可以來量化地描述軟件過程和軟件產(chǎn)品的不同方面的特點。p過程度量的要素p產(chǎn)品度量的要素p軟件度量的作用（1）項目計劃（2）控制項目過程（3）分析和改進組織過程p定義：PDB 是存放從項目可獲得的過程性能數(shù)據(jù)的數(shù)據(jù)庫，這些數(shù)據(jù)可以用于項目計劃、估計、生產(chǎn)率和質量分析等。p PDB的構成：由已經(jīng)完成的項目的數(shù)據(jù)構成 項目特征 項目進度 項目工作量 項目規(guī)模 故障 風險 pPDB的建立及訪問 PDB由SEPG建立 項目經(jīng)理可以閱讀p 過程能力基線（PCB）的主要內(nèi)容 已交付軟件的質量 生產(chǎn)率 進度計劃 工作量分布 故障引入率 過程中故障排

33、除率 質量成本 故障分布p過程財富的組成 組織標準軟件過程 組織的軟件過程數(shù)據(jù)庫/過程能力基線 軟件生命周期描述 標準軟件過程的剪裁指南和準則 軟件有關文檔 1. 工作量估計模型概述2. 估計方法- 自底向上的估計方法- 自頂向下的估計方法3. 進度安排p工作量估計模型 自頂向下的估計方法 規(guī)模估計整體工作量各階段工作量 COCOMO 模型 自底向上的估計方法 各階段的工作量整體的工作量 此方法可以直接估計工作量 工作量估計模型概述p 自底向上估計 任務分解每個程序單元的復雜度定義估計每個單元的編碼工作量計算整個程序的編碼工作量導出整體項目的工作量各階段的工作量估計方法 程序單元分類的準則各種

34、平臺，各種語言，各種環(huán)境分類的標準不一樣。 方法的有效性估計工作量與實際工作量的比較估計方法 規(guī)模估計：整體工作量-各階段工作量 軟件規(guī)模估計的主要估算方法： 代碼行（LOC/KLOC）法 功能點法 估計方法p COCOMO模型- 基本COCOMO模型 - 中級COCOMO模型 估計方法 整體進度計劃 詳細進度計劃（主要里程碑）1. 質量管理2.量化質量管理計劃p 軟件質量和缺陷 軟件質量的定義：我們用已交付軟件的故障密度作為軟件質量的定義即，已交付軟件中每個單位規(guī)模的故障數(shù)。 質量管理的任務是規(guī)劃合理的質量控制任務，然后正確地執(zhí)行和控制它們，以實現(xiàn)項目的質量目標。 故障排除任務包括需求評審、

35、設計評審、代碼評審、單元測試、集成測試、系統(tǒng)測試和驗收測試。 p 質量管理的量化方法 兩個關鍵工作： 設定量化質量目標 量化管理軟件開發(fā)過程 設定質量目標 質量過程計劃 其他階段的缺陷估計1. 背景2. 風險評估3. 風險控制 風險管理（Risk Management）試圖使由于意外事件而導致項目失敗的概率降到最小。 主要包括： 風險評估 風險控制 風險和風險管理概念 什么是風險：風險是那些可能發(fā)生的事件或者條件，如果它確實發(fā)生了，則它的發(fā)生會對項目產(chǎn)生有害的或者負面的影響。另一方面，風險是一種概率事件，可能發(fā)生也可能不發(fā)生。 風險管理的目標：旨在識別出風險，然后采取措施使它們對項目的影響最小

36、 特點：風險管理是要付出額外的成本；風險管理的價值不容易度量 風險識別 識別風險常用的方法 風險等級劃分 根據(jù)風險暴露度劃分（RE） RE(r)=Prob (r) *Loss (r) 風險管理規(guī)劃 任務是確定使風險后果最小所需的措施，也稱風險緩和措施。 風險監(jiān)督和跟蹤 項目管理計劃(Project Management Plan, PMP)是項目經(jīng)理承擔的所有規(guī)劃任務的核心。各規(guī)劃任務的結果都出現(xiàn)在PMP中，是指導所有項目執(zhí)行的基準文檔。 項目管理計劃分四部分： 項目概述 項目計劃 項目跟蹤 團隊 項目管理計劃的主要使用者： 業(yè)務主管 項目經(jīng)理 項目的開發(fā)人員 項目的起止日期、項目經(jīng)理、項目目

37、標、與客戶的聯(lián)系、對客戶的主要承諾以及所做的假設前提。 項目過程 標準過程的描述、剪裁指南、需求變更管理 工作量估計 開發(fā)環(huán)境 工具 培訓計劃 質量計劃 里程碑 風險管理計劃 任務跟蹤 事宜跟蹤 客戶反饋 狀態(tài)報告 升級規(guī)程 項目機構 項目組 角色和職責 軟件配置管理（Software Configuration Management，SCM ）是項目管理中專門用于關注系統(tǒng)地控制項目進行中發(fā)生的變更的那些部分，由用來識別組織軟件產(chǎn)品并控制其修改的一系列活動構成。 軟件配置管理（software configuration management, SCM）是項目管理的一項內(nèi)容，主要涉及對變更進行

38、系統(tǒng)地控制，建立和維護在項目的整個軟件生存周期中軟件項目產(chǎn)品的完整性。 主要包括：標識在給定時間點上軟件的配置，系統(tǒng)地控制對配置項的更改、并維護在整個軟件生存周期中配置的完整性和可跟蹤性。 p配置管理的功能與機制 配置管理的功能：（1、給出程序的狀態(tài)；2、給出一個程序的最新版本；3、處理并發(fā)更新申請；4、取消一個程序變更；5、防止未授權的變更或者刪除；6、提供需求變更申請和程序變更之間的可跟蹤性；7、取消一個需求變更；8、顯示相關的變更；9、收集當前系統(tǒng)的所有源代碼、文檔和其他信息。） 配置管理的機制包括：（1、文件命名和組織的約定；2、版本控制；3、變更申請的可跟蹤性；4、訪問控制；5、協(xié)調(diào)

39、過程；6、修改登記程序。） p 配置管理過程主要有： 配置規(guī)劃 配置執(zhí)行 狀態(tài)監(jiān)控 1. 標識出典型的配置項2. SCM人員或者項目經(jīng)理進行SCM規(guī)劃該階段的任務主要有： 配置控制任務主要有兩個： 涉及程序的狀態(tài)轉移管理 涉及必須被實現(xiàn)的變更申請的管理 變更申請的步驟：1、接受變更申請（影響分析之后）；2、建立一種跟蹤機制；3、檢出需要進行變更的配置項；4、執(zhí)行變更；5、注冊配置項；6、在項目的整個生命期內(nèi)維護該項目。 正確表示每一個配置項的狀態(tài) 進行配置項的定期狀態(tài)檢查，產(chǎn)生關于差異的報告，并解決所有差異 檢查變更請求的狀態(tài) 執(zhí)行配置審計 VSS使用教程 評審是最有效的也是最常用的標識故障的

40、方法，可以對文檔及代碼進行評審。評審還可以使管理人員掌握項目的進展。1、評審可以應用于軟件開發(fā)各個階段、產(chǎn)生的各種類型產(chǎn)品范圍廣；2、評審比軟件測試更有效率，因為他看到的是問題本身而不是征兆；3、通過評審不僅可能發(fā)現(xiàn)錯誤，還可以提出對軟件產(chǎn)品的改進意見，防止再發(fā)生；4、評審可以在產(chǎn)品開發(fā)階段進行，作者對產(chǎn)品細節(jié)很清楚，可以及時修改；5、不只發(fā)現(xiàn)錯誤，還有利于評審員、軟件項目相關組熟悉有關產(chǎn)品。 小組評審的幾個階段： 評審規(guī)劃、 準備和概述、 小組會議、 返工及后續(xù)修改 1. 評審規(guī)劃： 標識要評審的產(chǎn)品； 選擇評審成員及安排評審時間 作者準備好相應的材料。 2. 準備和概述： 此階段的目的：是

41、將要評審的軟件包交給評審人員，并在需要時，對工作產(chǎn)品進行說明。 第一次會議； 在正式會議之前，各評審員獨立地評審工作產(chǎn)品，作評審日志。 需要準備的材料：評審通知、評審標準、被評審的工作產(chǎn)品、正式的評審記錄單、評審檢查表、其他資料（如相關文檔、標準等） 3. 評審會議 評審會議的目的：最終拿出故障列表 會前檢查準備工作； 會議期間提出問題； 會議結束時，給出問題和故障列表。 結論分為：可以通過、不能通過和有條件通過 4. 返工和后續(xù)措施 作者執(zhí)行返工，以改正評審會議上提出的所有故障。 作者與評審主席一起審查改正情況。 在評審的各個階段，數(shù)據(jù)都要被記錄，每次評審的總結數(shù)據(jù)都被保存到一個評審數(shù)據(jù)庫中。 1 自備日志 2 小組評審會議日志 3. 小組評審總結報告 監(jiān)督和控制主要針對評審的效率。 沒有效率的評審是對時間和資源的巨大浪費。 項目監(jiān)督和控制的目的是：建立對項目的實際進展的適當?shù)目梢曅?，使管理者能在軟件項目性能明顯偏離軟件計劃時采取有效措施。 活動包括：對照已文檔化的估計和計劃，評審和跟蹤軟件完成情況和結果，基于實際的完成情況和結果調(diào)整原有