it項目管理教程課件

1、IT項目管理 2022/8/41第1頁，共110頁。項目管理基礎2022/8/42第2頁，共110頁。 什么是項目？下面的工作中，哪些是項目，哪些不是項目？ 為某銀行客戶開發(fā)、安裝電話銀行系統(tǒng) 負責電話銀行系統(tǒng)的銷售工作 在2006年銷售20套以上的電話銀行系統(tǒng) 為某銀行客戶的電話銀行系統(tǒng)提供售后服務 建立售后服務熱線 管理售后服務熱線，接聽客戶來電，解決客戶問題 為客戶提供優(yōu)質服務 為人民服務2022/8/43第3頁，共110頁。 什么是項目？下面的工作中，哪些是項目，哪些不是項目？ 為某銀行客戶開發(fā)、安裝電話銀行系統(tǒng) 負責電話銀行系統(tǒng)的銷售工作 在2006年銷售20套以上的電話銀行系統(tǒng) 為

2、某銀行客戶的電話銀行系統(tǒng)提供售后服務 建立售后服務熱線 管理售后服務熱線，接聽客戶來電，解決客戶問題 為客戶提供優(yōu)質服務 為人民服務 2022/8/44第4頁，共110頁。項目的特征項目有一個明確界定的目標項目的執(zhí)行要通過完成一系列相互關聯的任務項目需運用各種資源來執(zhí)行任務項目有具體的時間計劃或有限的壽命項目可能是獨一無二、一次性的努力每個項目都有客戶項目包含一定的不確定性2022/8/45第5頁，共110頁。什么是項目管理？項目管理是在項目活動中運用知識、技能、工具和技術，以便滿足和超過項目干系人對項目的需求和期望。 制約項目成功的因素（判斷項目成功的標準） 范圍（符合客戶的需求和期望） 成

3、本（費用） 進度（時間） 質量（客戶滿意度）2022/8/46第6頁，共110頁。項目的生命周期一般項目的生命周期執(zhí)行項目結束項目識別需求投入力量提出解決方案時間2022/8/47第7頁，共110頁。組織結構不同企業(yè)的組織結構不同，不同的組織結構對項目管理的影響不同職能型組織項目型組織矩陣型組織弱矩陣型組織平衡矩陣組織強矩陣組織復合型組織2022/8/48第8頁，共110頁。職能型組織總經理員工財務部門經理采購部門經理生產部門經理設備部門經理員工員工員工員工員工員工員工員工員工員工員工項目協(xié)調2022/8/49第9頁，共110頁。項目型組織總經理員工項目經理項目經理項目經理項目經理員工員工員工

4、員工員工員工員工員工員工員工員工項目協(xié)調2022/8/410第10頁，共110頁。弱矩陣型組織總經理員工財務部門經理采購部門經理生產部門經理設備部門經理員工員工員工員工員工員工員工員工員工員工員工項目協(xié)調2022/8/411第11頁，共110頁。平衡矩陣型組織總經理員工財務部門經理采購部門經理生產部門經理設備部門經理員工項目經理項目經理員工員工員工員工員工員工員工員工項目協(xié)調2022/8/412第12頁，共110頁。強矩陣型組織總經理項目經理項目經理部經理采購部門經理生產部門經理設備部門經理項目經理項目經理員工員工員工員工員工員工員工員工員工項目協(xié)調2022/8/413第13頁，共110頁。復

5、合型組織總經理員工財務部門經理采購部門經理生產部門經理項目經理部經理員工項目經理員工員工員工員工員工員工員工 項目項目經理項目經理項目2022/8/414第14頁，共110頁。組織結構職能型組織弱矩陣型組織平衡矩陣型組織強矩陣型組織項目型組織項目經理的權威很少或沒有有限小到中等中等到大大到全權全時為項目工作的人員百分比幾乎沒有0-25%15-60%50-95%85-100%項目經理的角色部分時間部分時間全時全時全時項目經理角色的常用頭銜項目協(xié)調員/項目主管項目協(xié)調員/項目主管項目經理/項目主任項目經理/計劃經理項目經理/計劃經理2022/8/415第15頁，共110頁。案例：微軟公司產品部門的

6、組織結構圖產品部門總經理Product Unit Manager程序經理部經理Group PM程序經理組長PM Lead程序經理PM開發(fā)部經理Dev Manager開發(fā)組長Dev Lead開發(fā)工程師Dev測試部經理Test Manager測試組長Test Lead測試工程師Test2022/8/416第16頁，共110頁。項目經理Jeffrey Pinto和Om Kharbanda : 項目經理的12項工作準則：弄清自己面臨的問題、機會和期望明白項目團隊中的沖突是必然和自然的弄清楚誰是利益關系人，他們的目標是什么意識到組織的政治色彩，利用政治手段獲得優(yōu)勢擁有領導才能，能夠隨機應變明白判斷項目成

7、功的標準：范圍、成本、進度、質量 2022/8/417第17頁，共110頁。項目經理Jeffrey Pinto和Om Kharbanda : 項目經理的12項工作準則：充當團隊成員的激勵者、教練、活躍氣氛者、維和人員和沖突裁決人認識到自身的情緒，無論是正面的還是負面的，都將對團隊成員產生影響經常做“如果，那么”的假設，避免安于現狀不因小事而停滯不前，不要迷失項目目標有效利用時間首要任務是：計劃、計劃、計劃2022/8/418第18頁，共110頁。項目經理項目經理的職責計劃范圍界定、進度計劃、成本計劃、質量計劃組織組織項目資源項目中最重要的資源是人力資源對人力資源的組織包括分配工作和授權控制控制

8、項目范圍、進度、成本和質量項目風險管理和項目變更管理2022/8/419第19頁，共110頁。項目經理的技能領導能力人員開發(fā)能力溝通技巧人際交往能力處理壓力的能力解決問題的能力管理時間的技能2022/8/420第20頁，共110頁。授權授權不是推卸責任授權的范圍和時間必須明確讓被授權者明確期望的結果賦予被授權者必須的資源選擇最合適的人，給予信任和鼓勵一旦授權，被授權人在職責范圍內就擁有決策權和工作的自由2022/8/421第21頁，共110頁。不同程度的授權調查問題，告訴我所有的情況，我決定做什么，怎么做調查問題，告訴我可行的其他方案并推薦一種，我評價后決定調查問題，告訴我你可能會采取什么行動

9、，需要我批準調查問題，告訴我你可能采取的行動，如果我不反對，就執(zhí)行調查問題并采取行動，讓我知道你是怎么做的調查問題并采取行動，是否向我報告由你決定最低授權最高授權2022/8/422第22頁，共110頁。項目團隊B. W. Tuckman定義了團隊發(fā)展的4個階段：形成階段震蕩階段正規(guī)階段表現階段形成階段震蕩階段正規(guī)階段表現階段2022/8/423第23頁，共110頁。項目團隊沖突的7種來源：工作內容（方法上、工作量上和質量標準上）資源分配進度計劃成本先后次序組織問題個體差異2022/8/424第24頁，共110頁。項目團隊處理沖突的5種方法：回避或撤退競爭或逼迫調?；蛳讌f(xié)合作、正視和解決問

10、題2022/8/425第25頁，共110頁。項目團隊解決問題的9個步驟：對問題作出說明找出問題的可能原因（頭腦風暴法）收集數據、確定最有可能的原因得出可能方案評估可行方案決定最佳方案修訂項目計劃實施方案判斷問題是否得到解決2022/8/426第26頁，共110頁。項目團隊管理時間培養(yǎng)項目成員計劃和充分利用時間的能力項目經理有責任幫助項目成員排除外界的干擾2022/8/427第27頁，共110頁。項目計劃與進度控制明確目標，界定范圍一句話的項目一頁紙的項目目標說明詳細的項目范圍說明文檔微軟公司IE 4.0的產品目標此次計劃推出的IE瀏覽器將成為Internet上的主流瀏覽器軟件，它可以為企業(yè)客戶

11、和最終用戶提供高速、穩(wěn)定、總體擁有成本最低的使用體驗，可以與Microsoft的Office軟件有效集成，這一產品的市場目標是在1998年將IE的市場占有率擴大到65%2022/8/428第28頁，共110頁。項目分解結構（WBS) 項目分解結構的主要目的和用途是：1）明確和準確說明項目的范圍；2）為各獨立單元分派人員，規(guī)定這些人員的相應職責；3）針對各獨立單元，進行時間、費用和資源需要量的估算，4）確定項目進度測量和控制的基準；5）將項目工作與項目的財務帳目聯系起來；6）自上而下將項目目標落實到具體的工作上7）確定工作內容和工作順序；8）估計項目整體和全過程的費用。2022/8/429第29

12、頁，共110頁。技 術 改 造 項 目可行性研究審 批設 計籌 資實 施安裝完成I改建施工O試運行N軟件調試M職工培訓L設備安裝E改建籌資K軟件編程J設備改造G設備籌資B 審 批F設備設計D改建設計H軟件系統(tǒng)設計C設計任務書A.可行性研究 某技術改造項目工作分解結構2022/8/430第30頁，共110頁。2022/8/431第31頁，共110頁。確定活動順序1.活動之間的邏輯關系2.活動順序安排的方法 網絡計劃技術2022/8/432第32頁，共110頁。項目活動之間四種依賴關系1、結束對起始FS前一活動必須在后一活動開始前結束。2、結束對結束FF前一活動必須在后一活動結束前結束。3、起始對

13、起始SS前一活動必須在后一活動開始前開始。4、起始對結束SF前一活動必須在后一活動結束前開始。2022/8/433第33頁，共110頁。準確描述活動間關系FS, SS, FF, SF2022/8/434第34頁，共110頁。任務搭接示例示例：任務的搭接關系具有兩天完成到開始延遲搭接的項目橫道圖2022/8/435第35頁，共110頁。任務搭接示例示例：任務的搭接關系具有兩天完成到開始搭接的項目網絡圖中的日期2022/8/436第36頁，共110頁。關鍵路徑法(CPM) （1）關鍵路徑定義 （2）確定關鍵路徑 2022/8/437第37頁，共110頁。最早開始和最早結束時間1、最早開始時間（ea

14、rliest start time,ES)是指某項活動能夠開始的最早時間。2、最早結束時間(earliest finish time,EF)是指某項活動能夠完成的最早時間。 EF=ES+工期估計規(guī)則：某項活動的最早開始時間必須相同或晚于直接指向這項活動的最早結束時間中的最晚時間。2022/8/438第38頁，共110頁。最遲開始和結束時間1、最遲結束時間（latest finish time,LF)是指為了使項目在要求完工時間內完成，某項活動必須完成的最遲時間。2、最遲開始時間（latest start time,LS)是指為了使項目在要求完工時間內完成，某項活動必須開始的最遲時間。 LS=L

15、F-工期估計 （LS和LF通過反向推出）規(guī)則：某項活動的最遲結束時間必須相同或早于該活動直接指向的所有活動最遲開始時間的最早時間。2022/8/439第39頁，共110頁。網絡計劃技術正向計算正向計算 目的：計算最早時間方法：根據邏輯關系方向：從網絡圖始端向終端計算第一個任務的開始為項目開始時間任務完成時間為開始時間加持續(xù)時間后續(xù)任務開始時間根據前置任務的時間和搭接時間而定多個前置任務存在時，根據最遲的任務時間定2022/8/440第40頁，共110頁。正向計算結果示例：正向計算結果-最早時間正向計算后的網絡數據（最下排顯示的數據是最早開始日期和最早完成日期）2022/8/441第41頁，共1

16、10頁。網絡計劃技術反向計算反向計算 - 計算最晚時間目的：計算最晚時間方法：根據邏輯關系方向：從網絡圖終端向始端計算最后一個任務的完成時間為項目完成時間任務開始時間為完成時間減持續(xù)時間前置任務完成時間根據后續(xù)任務的時間和搭接時間而定多個后續(xù)任務存在時，根據最早的任務時間定2022/8/442第42頁，共110頁。反向計算結果示例：反向計算結果-最晚時間反向計算后的網絡數據（最下排顯示的數據是最晚開始日期和最晚完成日期）2022/8/443第43頁，共110頁。有關時差定義時差（slack):在不影響項目最后完成時間的前提下，某活動可以推遲開始的最大時間量?？倳r差（total slack,TS

17、)：在不影響項目最后完成時間的前提下，項目可以推遲開始的最大時間量。TS=LF-EF或LS-ES2022/8/444第44頁，共110頁。關鍵路徑（critical path)關鍵路徑：從項目開始到項目完成有許多條路徑，在整個網絡圖中最長的路徑就叫關鍵路徑。非關鍵路徑（noncritical path): 在整個網絡圖中非最長的路徑都叫非關鍵路徑。2022/8/445第45頁，共110頁。確定關鍵路徑確定關鍵路徑：找出那些具有最小時差的活動時差 = 最晚開始時間 - 最早開始時間 = 最晚完成時間 - 最早完成時間時差等于0和小于0的任務組成關鍵路徑2022/8/446第46頁，共110頁。確

18、定關鍵路徑時差計算和關鍵路徑確定2022/8/447第47頁，共110頁。進度管理里程碑(Milestone) 標記項目中重要事件的參考點，用于監(jiān)視項目的進度和可交付成果。2022/8/448第48頁，共110頁。進度管理進度控制方法分析進度，找出哪些地方需要采取糾正措施確定應采取哪種具體的糾正措施修改計劃，將糾正措施列入計劃重新計算進度，估計計劃采取的糾正措施的效果2022/8/449第49頁，共110頁。進度管理時間-成本平衡法開始DN=8:30 000美元C=6:42 000美元CN=10:40 000美元C=9:45 000美元BN=9:80 000美元C=6:110 000美元AN=

19、7:50 000美元C=5:62 000美元結束2022/8/450第50頁，共110頁。進度管理時間-成本平衡法 縮短工期的單位時間成本=（應急成本-正常成本）（正常時間-應急時間）開始DN=8:30 000美元C=6:42 000美元CN=10:40 000美元C=9:45 000美元BN=9:80 000美元C=6:110 000美元AN=7:50 000美元C=5:62 000美元結束A:6,000/周B:10,000/周C:5,000/周D:6,000/周2022/8/451第51頁，共110頁。資源管理資源包括人、場地、工具、設備等。項目中最重要的資源是人力資源。資源的分配和使用都

20、可以用成本來衡量。資源分配發(fā)生沖突又無法獲得更多資源時，需要對項目計劃進行調整（其結果是延長工期）資源約束下的進度安排（Resource-limited Scheduling）2022/8/452第52頁，共110頁。成本管理成本估計和項目預算根據項目計劃和項目資源分配情況估計項目成本將總預算成本分配到所有任務中。計算每一項任務在每個單位時間(如每周或每月)內的成本花費。2022/8/453第53頁，共110頁。軟件開發(fā)項目管理2022/8/454第54頁，共110頁。 美國項目管理狀況（1）IT項目管理現狀Standish Group 對于IT 8400個項目（投資250億美圓）的研究結果：

21、項目實現其目標 16% 項目需要補救 50% 徹底失敗 34%2022/8/455第55頁，共110頁。美國項目管理狀況（2）項目平均預算超出90%，進度超出120%項目總數33%既超出預算又進度推遲 52.7% 的項目費用是原估算的189 %以上. 只有16.2%項目按預算和進度完成 平均時間超出量是原估算的222% - 在大公司，只有9% 的項目按預算，按進度完成2022/8/456第56頁，共110頁。美國項目管理狀況(3)最近參與的項目費用執(zhí)行情況：嚴重費用超支 17%一定程度費用超支 38%完全按預算執(zhí)行 27%一定程度費用節(jié)余 12%大量費用節(jié)余 6%2022/8/457第57頁，

22、共110頁。美國項目管理狀況(4)最近參與的項目滿足進度要求程度嚴重拖期 35%一定程度拖期 34%按時完成 22%一定程度提前 8%大量提前 1%2022/8/458第58頁，共110頁。軟件項目失敗的五大原因不完整的需求描述 10%15%缺少用戶參與 10%15%缺乏資源 10%15%不現實的項目目標 10%缺少管理層的支持 5%10%來源：Standish Group 2022/8/459第59頁，共110頁。國際項目管理組織(1)美國項目管理協(xié)會 PMI （Project Management Institute)創(chuàng)建：60年代，性質：國際性組織分會：245個成員：企業(yè)、高校、研究單位

23、職能：促進國際間項目管理發(fā)展第60頁，共110頁。國際項目管理組織(2)國際項目管理協(xié)會IPMA(International Project Management Association）創(chuàng)建：1965，性質：非盈利的國際性組織成員：國家級項目管理協(xié)會職能：促進國際間項目管理發(fā)展產品和服務：研究和發(fā)展，教育與培訓，標準和資質認證第61頁，共110頁。國際項目管理知識體系美國PMI項目管理的知識體系PMBOK (Project Management Body of Knowledge)九個知識領域國際IPMA項目管理能力基礎ICB (IPMA Competence Baseline)42個知識和

24、實踐元素，其中核心元素28個，增加元素14個。第62頁，共110頁。CMM簡介CMM能力成熟度模型( Capability Maturity Model) 是一種幫助軟件開發(fā)組織改進軟件過程的策略 由卡內基梅隆大學軟件工程研究所提出 1.初始級（Initial） 2.可重復級（Repeatable） 3.已定義級（Defined） 4.已管理級（Management） 5.優(yōu)化級（Optimizing）2022/8/463第63頁，共110頁。MSF簡介什么是MSF？微軟解決方案框架（Microsoft Solution Framework）是微軟公司根據自身的實踐經驗為企業(yè)設計的一套有關軟件

25、開發(fā)的模型、準則和成功經驗；借助微軟解決方案框架，企業(yè)可以更有效地開發(fā)、管理和使用IT系統(tǒng)，更好地解決企業(yè)面臨的商務問題。微軟解決方案框架的設計目標是為企業(yè)IT系統(tǒng)的規(guī)劃(Planning)、建設(Building)和管理(Managing)提供支持和幫助2022/8/464第64頁，共110頁。MSF的主要模型企業(yè)架構模型（Enterprise Architecture Model） 業(yè)務（Business） 信息（Information） 技術（Technology） 應用（Application）2022/8/465第65頁，共110頁。MSF的主要模型解決方案設計模型（Solution

26、s Design Model）概念設計（Conceptual Design）：概念設計來源于最終用戶的需求，它的作用是確定業(yè)務目標，明確最終用戶想要做什么，需要什么樣的系統(tǒng)或產品邏輯設計（Logical Design）：邏輯設計是由項目組完成的。它的作用是根據業(yè)務需求提出要開發(fā)的應用系統(tǒng)的細節(jié)特性。物理設計（Physical Design）：物理設計是由開發(fā)者完成的。它的作用是將邏輯設計轉變成為具體的技術設計，如實現方法和性能優(yōu)化等。 2022/8/466第66頁，共110頁。MSF的主要模型風險管理模型（Risk Management Model） 風險管理模型提供了定義、預測、控制和管理項

27、 目風險的基本框架。它為預測、處理和控制項 目風險，確定風險的優(yōu)先級，以及制定相關的 風險管理策略提供了一系列準則和方法。 使用風險管理模型可以幫助我們：關注項目中的關鍵因素關鍵的時間做出正確的決定為將來可能發(fā)生的未知事件作好準備2022/8/467第67頁，共110頁。MSF的主要模型應用模型（Application Model）基于服務網絡的應用程序模型應用程序1應用程序2用戶服務層業(yè)務服務層數據服務層2022/8/468第68頁，共110頁。MSF的主要模型組隊模型（Team Model）組隊模型為項目組的組織結構提供了一個靈活的方案。MSF組隊模型更注重對項目組成員的考察和定義，它具有

28、相當高的靈活性和適應性，這也是微軟解決方案框架與其它項目管理體系，如CMM的重要區(qū)別之一。過程模型（Process Model）過程模型提供了一種基于里程碑的、可交互的、靈活的項目生命周期管理框架和指南。它涵蓋了項目的階段劃分、里程碑定義、任務分配、產品交付等方面的內容。后面將給出這兩種模型的詳細介紹2022/8/469第69頁，共110頁。MSF組隊模型在那些有著嚴格的經費預算和確定的時間期限、其組員在處理問題時享有充分自由的小型項目組中，人們通常擁有最高的生產效率2022/8/470第70頁，共110頁。MSF組隊模型的基本原則小型的、多元化的項目組角色依賴和職責共享專深的技術水平和業(yè)務技

29、能以產品發(fā)布為中心明確的目標客戶的主動參與分享產品的前景所有人都參與設計認真從過去的項目中吸取經驗共同管理，共同決策項目組成員在同一地點辦公大項目組也像小項目組一樣運轉2022/8/471第71頁，共110頁。MSF組隊角色程序管理角色開發(fā)角色測試角色發(fā)布管理角色用戶體驗角色產品管理角色溝通2022/8/472第72頁，共110頁。產品管理角色（Product Management）在項目組中扮演客戶代言人的角色確保項目組成員對項目前景和項目范圍了如指掌管理客戶的需求意義開發(fā)、管理和提供業(yè)務用例說明（Business Case）管理客戶的預期目標控制產品特性和開發(fā)周期之間的關系管理市場宣傳和公

30、共關系2022/8/473第73頁，共110頁。程序管理角色（Program Management）推動產品開發(fā)過程管理產品范圍和產品特性說明推動項目組內的交流和討論管理產品開發(fā)速度，匯報項目狀態(tài)控制項目開發(fā)中關鍵的取舍和決策2022/8/474第74頁，共110頁。程序經理(Program Manager)和項目經理(Project Manager)的區(qū)別編寫設計文檔贏得的權利管理項目一組人負責不編寫設計文檔授予的權利管理人一人負責項目經理程序經理2022/8/475第75頁，共110頁。開發(fā)角色(Development)完成產品特性的物理設計在項目組內承擔技術顧問的職責確保每一個產品特性在

31、規(guī)定的時間內完成使產品達到可發(fā)布的狀態(tài)2022/8/476第76頁，共110頁。測試角色(Testing)制定測試策略和測試計劃確保產品的所有特性都經過了嚴格的測試向項目組提供翔實、準確的測試報告2022/8/477第77頁，共110頁。用戶體驗角色(User Experience)在產品設計階段確保產品可被最終用戶接受對產品的國際化功能提供支持設計和開發(fā)產品的技術支持系統(tǒng)用戶培訓確保產品的可用性圖形用戶界面設計2022/8/478第78頁，共110頁。發(fā)布管理者角色(Release Management)代表項目組協(xié)調公司內的運營、支持、發(fā)布渠道等部門的工作項目組的后勤和基礎設施管理產品發(fā)布

32、事宜參與和管理、支持相關的項目決策過程管理產品的認證或許可模式，創(chuàng)建并分發(fā)產品的序列號、許可協(xié)議等2022/8/479第79頁，共110頁。MSF組隊模型不是組織結構圖產品經理用戶培訓人員開發(fā)人員系統(tǒng)分析員發(fā)布管理人員開發(fā)人員測試人員2022/8/480第80頁，共110頁。對等團隊結構(Team of peers)程序經理開發(fā)經理測試經理發(fā)布和后勤經理用戶經理產品經理溝通2022/8/481第81頁，共110頁。MSF組隊模型的六大工作目標組隊角色工作目標產品管理角色提高顧客滿意度程序管理角色在有限時間和資源條件下開發(fā)產品開發(fā)角色嚴格依據用戶的業(yè)務需求和產品功能說明書開發(fā)產品測試角色在充分測

33、試、定位了所有已知問題的前提下發(fā)布產品用戶體驗角色增強產品的可用性發(fā)布管理角色做好產品的發(fā)布和相關的管理工作2022/8/482第82頁，共110頁。組隊模型的靈活應用小型項目組中的角色合并按產品特性劃分項目組按職能劃分項目組2022/8/483第83頁，共110頁。小型項目組中的角色合并產品管理程序管理開發(fā)測試用戶體驗發(fā)布管理產品管理NNPPU程序管理NNUUP開發(fā)NNNNN測試PUNPP用戶體驗PUNPU發(fā)布管理UPNPUN不能合并 U不建議合并 P可以合并2022/8/484第84頁，共110頁。小型項目組中的角色合并程序管理發(fā)布管理開發(fā)測試產品經理用戶體驗2022/8/485第85頁，

34、共110頁。按產品特性劃分項目組程序管理用戶體驗產品管理開發(fā)測試發(fā)布管理程序管理開發(fā)測試程序管理開發(fā)測試程序管理開發(fā)測試領導小組接待功能開發(fā)組客房預定功能開發(fā)組結帳功能開發(fā)組2022/8/486第86頁，共110頁。按職能劃分項目組產品總體管理市場工作產品規(guī)劃市場調研宣傳公共關系程序總體管理版本管理項目協(xié)調產品架構設計開發(fā)管理用戶界面數據庫系統(tǒng)服務2022/8/487第87頁，共110頁。按職能劃分項目組測試管理集成測試壓力測試功能測試配置測試用戶體驗管理文檔編輯用戶資源設計媒體管理本地化發(fā)布管理項目運營系統(tǒng)管理渠道管理內部培訓支持平臺項目溝通2022/8/488第88頁，共110頁。項目組內

35、外的交流和溝通產品管理開發(fā)測試最終用戶發(fā)布管理運營和支持部門最終用戶客戶業(yè)務設計和規(guī)劃人員技術委員會程序管理用戶體驗項目組商業(yè)視角技術視角2022/8/489第89頁，共110頁。MSF過程模型什么是MSF過程模型？ MSF過程模型是一種基于階段的，由里程碑驅動的、遞進的軟件開發(fā)模型2022/8/490第90頁，共110頁。傳統(tǒng)瀑布模型2022/8/491第91頁，共110頁。傳統(tǒng)螺旋模型2022/8/492第92頁，共110頁。MSF過程模型2022/8/493第93頁，共110頁。MSF過程模型的特點目標驅動而非任務驅動外部可見的里程碑應提交項的變更管理遞進的版本發(fā)布策略風險驅動的進度管理

36、項目組集體參與管理產品質量2022/8/494第94頁，共110頁。MSF過程模型的基本原則制定計劃時兼顧未來的不確定因素通過有效的風險管理減少不確定因素的影響經常生成產品和快速測試快速循環(huán)、遞進的開發(fā)過程從產品特性開發(fā)和成本控制出發(fā)創(chuàng)造性地工作創(chuàng)建確定的進度表使用小型項目區(qū)并發(fā)完成工作，并設置多個同步點將大型項目分解成多個可管理的單元，以便更快地發(fā)布產品用產品的前景目標和概要說明直到項目開發(fā)工作避免產品走形使用概念驗證原型進行開發(fā)前的測試零缺陷概念非責難式的里程碑評審會2022/8/495第95頁，共110頁。MSF過程模型的階段劃分和里程碑設置發(fā)布完成Deployment Complete

37、可發(fā)布版本準備就緒Release Readiness Approved開發(fā)完成Scope Complete項目管理計劃得到認可Project PlansApproved前景/范圍得到認可Vision/ScopeApproved發(fā)布階段Deploying Phase開發(fā)階段Developing Phase穩(wěn)定階段Stabilizing Phase計劃階段Planning Phase構想階段Envisioning Phase2022/8/496第96頁，共110頁。里程碑管理主要里程碑和臨時里程碑里程碑是由目標驅動的里程碑式項目的同步點里程碑主要的推動者前景/范圍得到認可產品管理角色項目計劃得到認

38、可程序管理角色開發(fā)完成開發(fā)和用戶體驗角色可發(fā)布版本準備就緒測試和發(fā)布管理角色發(fā)布完成發(fā)布管理角色2022/8/497第97頁，共110頁。均衡三角形資源特性進度2022/8/498第98頁，共110頁。項目均衡矩陣（Project Tradeoff Matrix）資源特性進度資源進度特性可調整可選固定2022/8/499第99頁，共110頁。項目均衡矩陣(Project Tradeoff Matrix)在_一定的情況下，我們可以選擇_,并對_作必要的調整。通過邏輯組合不難知道，可能的填充結果有六種：在資源一定的情況下，我們可以選擇進度，并對產品特征作必要的調整。在資源一定的情況下，我們可以選擇

39、產品特性，并對進度作必要的調整。在產品特性一定的情況下，我們可以選擇資源，并對進度作必要的調整。在產品特性一定的情況下，我們可以選擇進度，并對資源作必要的調整。在進度一定的情況下，我們可以選擇資源，并對產品特性作必要的調整。在進度一定的情況下，我們可以選擇產品特性，并對資源作必要的調整。2022/8/4100第100頁，共110頁。遞進的版本發(fā)布策略版本1版本2版本32022/8/4101第101頁，共110頁。構想階段(Envision Prase)里程碑：前景/范圍得到認可項目構想階段的應提交項包括：前景/范圍說明書風險評估說明書項目組織結構說明書角色任務產品管理負責全面工作；確認用戶需求

40、；編寫前景/范圍說明書程序管理負責設計工作；概念設計；項目組織結構開發(fā)開發(fā)系統(tǒng)原型；技術選型；可行性分析用戶體驗收集用戶在使用方面的需求和建設測試制定測試策略；建立測試標準發(fā)布管理運營和支持；建立運營標準2022/8/4102第102頁，共110頁。計劃階段(Planning Phrase)里程碑：項目計劃得到認可計劃階段產生的應提交項包括：功能說明書(Functional specification)風險管理計劃(Risk management plan)項目總體計劃書和總體進度表(Master project plan and master project schedule)角色任務產品管

41、理概念設計；業(yè)務需求分析；溝通計劃程序管理概念設計和邏輯設計；功能說明書；項目總體計劃書和進度表，預測開發(fā)技術驗證；邏輯和物理設計；開發(fā)計劃/進度表；開發(fā)預算用戶體驗編寫使用情境/用例，用戶需求；本地化/易用性需求；用戶文檔/培訓計劃/進度表測試設計論證；測試需求說明書；測試計劃/進度表發(fā)布管理設計論證；運營需求；發(fā)布計劃/說明書2022/8/4103第103頁，共110頁。開發(fā)階段(Developing Phrase)里程碑：開發(fā)完成計劃階段產生的應提交以下內容：源代碼和可執(zhí)行程序(Source code and executables)安裝腳本和用于發(fā)布的配置信息(Installation

42、 scripts and configuration setting for deployment)已凍結的功能說明書(Frozen functional specification)關于產品使用的支持要素(Performance support elements)測試說明書和測使用例(Test specifications and test cases)角色任務產品管理概念設計；業(yè)務需求分析；溝通計劃程序管理概念設計和邏輯設計；功能說明書；項目總體計劃書和進度表，預測開發(fā)技術驗證；邏輯和物理設計；開發(fā)計劃/進度表；開發(fā)預算用戶體驗編寫使用情境/用例，用戶需求；本地化/易用性需求；用戶文檔/培

43、訓計劃/進度表測試設計論證；測試需求說明書；測試計劃/進度表發(fā)布管理設計論證；運營需求；發(fā)布計劃/說明書2022/8/4104第104頁，共110頁。穩(wěn)定階段(Stabilizing Phrase)里程碑：可發(fā)布版本準備就緒計劃階段產生的應提交項包括：黃金版本(Golden release)版本注釋(Release notes)關于產品使用的支持要素(Performance support elements)測試結果和測試工具(Test results and testing tools)源代碼和可執(zhí)行程序(Source code and executables)項目文檔(Project documents)里程碑評審記錄(Milestone review)角色任務產品管理執(zhí)行溝通計劃；制定執(zhí)行計劃程序管理項目跟蹤；Bug優(yōu)先級確定開發(fā)Bug修正；代碼優(yōu)化用戶體驗穩(wěn)定與用戶使用相關的資源