軟件研發(fā)項目管理課件

軟件研發(fā)項目管理2013-2-20軟件研發(fā)項目管理2013-2-20標題添加點擊此處輸入相關文本內(nèi)容點擊此處輸入相關文本內(nèi)容前言點擊此處輸入相關文本內(nèi)容標題添加點擊此處輸入相關文本內(nèi)容標題添加點擊此處輸入相點擊此處輸入前言點擊此處輸入標題添加點1研發(fā)項目管理基礎1計劃管理2需求管理3設計管理4開發(fā)管理5測試管理6目錄配置管理7最佳實踐82研發(fā)項目管理基礎1計劃管理2需求管理3設計管理4開發(fā)管理5測

基礎管理01

13基礎管理0113總綱與規(guī)范六為法需求必為準團隊必為本計劃必為綱績效必為證質(zhì)量必為出變化必為形4總綱與規(guī)范六為法需求必為準4總綱與規(guī)范七定法兵馬未動、合約先行（定需求）可行的做可行事（定技術(shù)方案）謀定而后動（定計劃）專業(yè)的人做專業(yè)的事（定人員）溝通無止境、共識促發(fā)展（定共識）死亡之地不可不察也（定風險）應對隨形、修道保法（定變更）5總綱與規(guī)范七定法兵馬未動、合約先行（定需求）5總綱與規(guī)范三出路以正合（用人之術(shù)，諸如選育用留）以曲制（規(guī)律之術(shù)，諸如過程方法）以奇勝（變化之術(shù)，諸如動靜之理）6總綱與規(guī)范三出路以正合（用人之術(shù)，諸如選育用留）6總綱與規(guī)范兵法一曰道目的二曰天制度三曰地需求四曰將專業(yè)角色五曰法過程7總綱與規(guī)范兵法一曰道目的7基礎管理----過程管理過程的簡單描述8基礎管理----過程管理過程的簡單描述8基礎管理----過程管理軟件研發(fā)的分類和組成軟件基本過程：軟件獲取、供應、開發(fā)、運行和維護的過程，包括需求分析、軟件設計、編碼等過程。軟件支持過程：對軟件主要過程提供支持的過程，包括文檔編制過程、配置管理過程、質(zhì)量保證過程、驗證和確認過程（測試過程）、評審過程等。軟件組織過程：對軟件主要過程和支持過程的組織保證過程，包括管理過程、基礎設施過程、改進過程和培訓過程。9基礎管理----過程管理軟件研發(fā)的分類和組成軟件基本過程：軟基礎管理----過程管理ISO/IEC15504軟件生存周期過程10基礎管理----過程管理ISO/IEC15504軟件生存周期基礎管理----過程規(guī)范軟件研發(fā)規(guī)范的建立軟件能力成熟度模型（CMM/CMMI）IBM-Rtaional統(tǒng)一過程（RUP）極限編程（eXtremeProgramming，XP）微軟軟件框架（MSF）11基礎管理----過程規(guī)范軟件研發(fā)規(guī)范的建立軟件能力成熟度模型基礎管理----過程規(guī)范瀑布模型螺旋模型、增量模型、迭代模型V模型并發(fā)過程模型極限編程（XP）IBM-Rational統(tǒng)一過程（RUP）軟件研發(fā)模型12基礎管理----過程規(guī)范瀑布模型軟件研發(fā)模型12基礎管理----過程規(guī)范不是好的東西都能用，適用的才是最好的!需要我們根據(jù)自己人員的水平、公司情況、業(yè)務狀況綜合確定適合自己的研發(fā)過程13基礎管理----過程規(guī)范不是好的東西都能用，13基礎管理14

計劃管理02

214基礎管理14計劃管理02214計劃管理軟件研發(fā)的項目管理有效的項目管理是在用來實現(xiàn)項目具體目標的規(guī)定時間內(nèi)，對組織機構(gòu)資源進行計劃、引導和控制工作。——《項目管理知識指南》15計劃管理軟件研發(fā)的項目管理15計劃管理WBS：

項目計劃形成之前，最好先畫WBS表（WorkBreakdownStructure），主要原理是：將任務逐級分解直至個人，在矩陣中體現(xiàn)為：先確定橫向有多少結(jié)點，再將每一結(jié)點任務逐漸細化直到個人，工作分解圖（WBS）實際上就是將一個復雜的開發(fā)系統(tǒng)分層逐步細化為一個個工作任務單元，這樣可以使我們將復雜、龐大的、不知如何下手的大系統(tǒng)劃分成了一個個獨立的我們能預測、計劃和控制的單元，從而也就達到了對整個系統(tǒng)進行控制的目的。16計劃管理WBS：項目計劃形成之前，最好先畫WBS表（WBS-工作分解結(jié)構(gòu)1項目范圍規(guī)劃

1.1 確定項目范圍

1.2 獲得項目所需資金

1.3 定義預備資源

1.4 獲得核心資源

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

2.1 行為需求分析

2.2 起草初步的軟件規(guī)范

2.3 制定初步預算

2.4 工作組共同審閱軟件規(guī)范/預算

2.5 根據(jù)反饋修改軟件規(guī)范

2.6 確定交付期限

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

2.9 分析工作完成3設計

3.1 審閱初步的軟件規(guī)范

3.2 制定功能規(guī)范

3.3 根據(jù)功能規(guī)范開發(fā)原型

3.4 審閱功能規(guī)范

3.5 根據(jù)反饋修改功能規(guī)范

3.6 獲得開展后續(xù)工作的批準

3.7 設計工作完成4開發(fā)

4.1 審閱功能規(guī)范

4.2 確定模塊化/分層設計參數(shù)

4.3 分派任務給開發(fā)人員

4.4 編寫代碼

4.5 開發(fā)人員測試(初步調(diào)試)4.6 開發(fā)工作完畢……計劃管理17WBS-工作分解結(jié)構(gòu)1項目范圍規(guī)劃 計劃管理17計劃管理創(chuàng)建WBS的基本法則每個工作工作單元在WBS只能出現(xiàn)一次概要任務是對其下所有任務的總結(jié)每個WBS的條目都有單獨的人員負責與實際要做的工作情形保持一致建立WBS時應讓項目組員參予每個WBS條目都應備案WBS既要靈活又要不失控制18計劃管理創(chuàng)建WBS的基本法則每個工作工作單元在WBS只能出現(xiàn)計劃管理項目估算令人煩惱的項目估算：這個項目需要多長時間？這個模塊大概多久完成？需要花費多少人力才能完成這個項目？項目的總成本大概為多少？

……19計劃管理項目估算令人煩惱的項目估算：19計劃管理項目成本的組成1.項目成本的組成（1）直接成本人力成本硬件設備軟件費用（2）間接成本項目管理成本一般管理成本20計劃管理項目成本的組成1.項目成本的組成20計劃管理責任矩陣用距陣的形式列出對某項任務負責的人或資源。任務管理人員項目經(jīng)理分析人員項目范圍規(guī)劃1.1確定項目范圍A1.2獲得項目所需資金A1.3定義預備資源A1.4獲得核心資源A分析/軟件需求2.1行為需求分析A2.2起草初步的軟件規(guī)范A2.3制定初步預算A2.4工作組共同審閱軟件規(guī)范/預算AP2.5根據(jù)反饋修改軟件規(guī)范A2.6確定交付期限A2.7獲得開展后續(xù)工作的批準AP2.8獲得所需資源A21計劃管理責任矩陣用距陣的形式列出對某項任務負責的人或資源。任計劃管理項目軟硬件資源管理1.軟件資源管理操作系統(tǒng)編譯器應用軟件測試工具……2.硬件資源管理服務器PC……22計劃管理項目軟硬件資源管理1.軟件資源管理22計劃管理10種常見的風險No.軟件風險相應對策1人員不足錄用優(yōu)秀人才；人員應適應崗位需要；全面考慮團隊建設；骨干人員工作要協(xié)調(diào)；實施培訓；預先安排關鍵人員的使用計劃2進度計劃和預算不準確詳細評估多種資源成本和進度；依成本進行設計；采用漸增式開發(fā)；軟件復用；純凈需求3開發(fā)了錯誤的軟件功能進行組織分析；實施任務分析；進行用戶調(diào)查；開發(fā)原型；及早編制用戶手冊4開發(fā)了不適用的用戶接口開發(fā)原型；制作腳本；作業(yè)分析；弄清了用戶特征(功能性、風格、工作負荷)5只追求表面效果，需求中含有一些不必要的功能（鍍金）純凈需求；開發(fā)原型；成本－效益分析；依成本進行設計6需求不斷變更重大變更設限；信息隱蔽；漸進式開發(fā)7外供部件不足制定基準點；檢驗；參考基準檢查；兼容性分析8外包任務問題參考基準檢查；發(fā)包前審核；未發(fā)包合同；競標設計或開發(fā)原型；建立團隊9實時性能達不到要求模擬；制定基準；建模；開發(fā)原型；安裝測量裝置；調(diào)準10誤解計算機科學能力技術(shù)分析；成本－效益分析；開發(fā)原型；參考基準檢查23計劃管理10種常見的風險No.軟件風險相應對策1人員不足錄用計劃管理項目跟蹤和控制1.了解成員的工作情況2.調(diào)整工作安排，合理利用資源3.促進計劃內(nèi)容的完善4.促進項目經(jīng)理對人員的認識5.促進對項目工作量的估計6.統(tǒng)計并了解項目總體進度7.有利于人員考核24計劃管理項目跟蹤和控制1.了解成員的工作情況24計劃管理現(xiàn)代軟件研發(fā)項目管理路線圖概覽25計劃管理現(xiàn)代軟件研發(fā)項目管理路線圖概覽25計劃管理項目預算與成本1、項目成本=直接成本*2.5直接成本為prj中的成本2、項目工期=基本工期+（悲觀時間-樂觀時間）/63、項目工期較長，可以分解為多個項目，每個項目不超過6個月，6個月內(nèi)按兩周做計劃。4、任務分解一般兩周:過粗不利分配工作,過細不利于人員的主動性.5、要識別任務關鍵路徑,根據(jù)人員情況并行或串行。26計劃管理項目預算與成本1、項目成本=直接成本*2.5直接成計劃管理WBSCHart27計劃管理WBSCHart27計劃管理ChartEXPERT28計劃管理ChartEXPERT28計劃管理關鍵路徑實例-Microsoftproject29計劃管理關鍵路徑實例-Microsoftproject需求管理30

需求管理03330需求管理30需求管理03330需求管理軟件研發(fā)的需求管理開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么?！ダ椎吕锟恕げ剪斂怂?1需求管理軟件研發(fā)的需求管理31需求管理軟件需求工程

所有與需求直接相關的活動統(tǒng)稱為需求工程，需求工程分為了兩個部分：需求開發(fā)和需求管理。其中，需求開發(fā)又分為了需求獲取、需求分析、需求定義和需求驗證4個部分，而需求管理則包含了變更控制、版本控制、需求跟蹤和需求狀態(tài)跟蹤

軟件需求包括三個不同的層次：業(yè)務需求、用戶需求和功能需求（也包括非功能需求）。32需求管理軟件需求工程所有與需求直接相關的活動需求管理軟件需求工程

業(yè)務需求（businessrequirement）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品的概括的目標要求，它在項目視圖與范圍文檔中予以說明。主要的目的是對企業(yè)目前的業(yè)務流程進行評估，得出一個業(yè)務前景。業(yè)務需求的確定對后面的用戶需求和功能需求起到了限制作用。

用戶需求(userrequirement)文檔描述了用戶使用系統(tǒng)而完成的任務的集合，用戶需求在用戶案例（usercase）文檔或方案腳本中予以說明。收集和分析用戶需求是不容易的，因為很多需求是隱形的，很難獲取，更難保證需求完整，而需求又是易變的，這就要求用戶和開發(fā)人員進行充分地交流。軟件需求(fsoftwarerequirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，它源于用戶需求。功能需求是軟件需求說明書中最重要的部分之一，它在開發(fā)、測試、質(zhì)量保證、項目管理以及相關項目功能中都起了重要的作用。非功能需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，包括要遵從的業(yè)務規(guī)則、人機接口、安全性和可靠性等要求。33需求管理軟件需求工程業(yè)務需求（businessrequi需求管理需求開發(fā)需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。獲取數(shù)據(jù)分析、處理目標系統(tǒng)模型需求獲取系統(tǒng)分析員從數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)出發(fā)，找出系統(tǒng)各元素之間的聯(lián)系、接口特征及設計限制、能否滿足功能需求34需求管理需求開發(fā)需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求需求管理需求獲取的方法需求研討會頭腦風暴用例模型訪談角色扮演原型法35需求管理需求獲取的方法需求研討會35需求管理基于用例的需求獲取執(zhí)行者的識別誰使用系統(tǒng)的主要功能？誰將提供、使用和刪除信息？誰負責維護、管理并保持系統(tǒng)正常運行？誰會對某一特定需求感興趣？系統(tǒng)的外部資源是什么？系統(tǒng)需要和哪些外部系統(tǒng)交互？用例的識別某個執(zhí)行者要求系統(tǒng)為其提供什么功能？該執(zhí)行者需要做哪些工作？執(zhí)行者需要閱讀、創(chuàng)建、銷毀、更新或存儲系統(tǒng)中哪些（類）信息？系統(tǒng)中的事件一定要告之執(zhí)行者嗎？執(zhí)行者需要告訴系統(tǒng)一些什么嗎？那些系統(tǒng)內(nèi)部的事件從功能的角度代表什么？由于新功能的識別，執(zhí)行者的日常工作被簡化或效率提高了嗎？系統(tǒng)需要什么樣的輸入輸出？輸入在哪里？輸出去往哪里？該系統(tǒng)的當前情況存在哪些問題？36需求管理基于用例的需求獲取36需求管理需求確認為什么需要需求評審？在哪個階段發(fā)現(xiàn)成本率需求1設計3-6編碼10功能測試15-40驗收測試30-70發(fā)布之后40-1000修訂一個缺陷的相關成本37需求管理需求確認為什么需要需求評審？在哪個階段發(fā)現(xiàn)成本率需求基礎管理需求跟蹤需求的標識<需求類型><需求#>需求類型可以是：F=功能需求，D=數(shù)據(jù)需求，B=行為需求，I=接口需求；O=輸出需求。

例：需求標識為F03的需求表示編號為3的功能需求。38基礎管理需求跟蹤需求的標識例：需求標識為F03的需求表示編號基礎管理39基礎管理39設計管理40

設計管理04

440設計管理40設計管理04440設計管理架構(gòu)開發(fā)方法41設計管理架構(gòu)開發(fā)方法41設計管理架構(gòu)開發(fā)方法42設計管理架構(gòu)開發(fā)方法42設計管理架構(gòu)開發(fā)方法43設計管理架構(gòu)開發(fā)方法43設計管理架構(gòu)是軟件的基石架構(gòu)是軟件的基礎，一個良好的架構(gòu)可以讓軟件有更長久的生命力，能發(fā)揮出更出色的性能；架構(gòu)師要求對業(yè)務有深入的了解，這樣才能讓架構(gòu)更符合軟件的需要，更能發(fā)揮軟件的特點。44設計管理架構(gòu)是軟件的基石架構(gòu)是軟件的基礎，一個良好的架構(gòu)可以設計管理45設計管理45設計管理46設計管理46設計管理47設計管理47設計管理48設計管理48開發(fā)管理

開發(fā)管理05549開發(fā)管理開發(fā)管理05549開發(fā)管理1.開發(fā)開發(fā)的目的包括：對照開發(fā)子系統(tǒng)的分層結(jié)構(gòu)定義代碼結(jié)構(gòu);以構(gòu)件（源文件、二進制文件、可執(zhí)行文件以及其他文件等）的方式開發(fā)類和對象;對已開發(fā)的構(gòu)件按單元來測試;將各開發(fā)員（或團隊）完成的結(jié)果集成到可執(zhí)行系統(tǒng)中。50開發(fā)管理1.開發(fā)開發(fā)的目的包括：對照開發(fā)子系統(tǒng)的分層結(jié)構(gòu)定開發(fā)管理2.過程策略里程碑：最初操作性能最初操作性能里程碑確定產(chǎn)品是否已經(jīng)可以部署到Beta測試環(huán)境。在最初操作性能里程碑，產(chǎn)品隨時可以移交給產(chǎn)品化團隊。此時，已開發(fā)了所有功能，并完成了所有Alpha測試（如果有測試）。除了軟件之外，用戶手冊也已經(jīng)完成，而且有對當前發(fā)布版的說明。評估標準該產(chǎn)品發(fā)布版是否足夠穩(wěn)定和成熟，可部署在用戶群中？是否已準備好將產(chǎn)品發(fā)布到用戶群？實際的資源耗費與計劃的相比是否仍可以接受？如果項目無法達到該里程碑，產(chǎn)品化可能要推遲一個發(fā)布版。51開發(fā)管理2.過程策略里程碑：最初操作性能最初操作性能里程碑確開發(fā)管理最佳開發(fā)實踐新概念與最佳實踐可持續(xù)開發(fā)節(jié)奏團隊激勵障礙列表持續(xù)集成產(chǎn)品燃盡圖Sprint燃盡圖52開發(fā)管理最佳開發(fā)實踐新概念與最佳實踐52開發(fā)管理

可持續(xù)開發(fā)節(jié)奏的相關概念

可持續(xù)的開發(fā)節(jié)奏是一個開發(fā)團隊可長期（可以認為是永久）保持的開發(fā)節(jié)奏為了保持可持續(xù)的開發(fā)節(jié)奏，適當?shù)男菁倏梢宰寛F隊及時恢復精力?？沙掷m(xù)的開發(fā)節(jié)奏并非禁止加班，但必須是偶然事件而非經(jīng)常性事件53開發(fā)管理

可持續(xù)開發(fā)節(jié)奏的相關概念

可持續(xù)的開發(fā)節(jié)奏是一個開開發(fā)管理討論當項目進度對于完成當前的迭代目標面臨壓力時，作為ScrumMaster，你會采取以下哪種方式？54開發(fā)管理討論當項目進度對于完成當前的迭代目標面臨壓力時，作為開發(fā)管理ScrumMaster要關注團隊的健康

高強度的開發(fā)節(jié)奏如果超過了團隊可承受的范圍，必然影響團隊的健康（包括心理和生理健康）。ScrumMaster應該關注團隊的健康狀況。選擇可持續(xù)的開發(fā)節(jié)奏，應該以團隊能夠感覺舒適地完成迭代目標為前提。55開發(fā)管理ScrumMaster要關注團隊的健康

高強度的開開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響56開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響56開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響Defect大量增加：持續(xù)加班狀況下代碼質(zhì)量很難保證，必然導致defect數(shù)量增加。工作效率降低：研究表明，當人疲勞時工作效率將急劇下降。團隊士氣低下：長期的高強度工作必然使團隊身心疲憊，士氣低落。開始相互推諉責任：長期高負荷工作下，導致出現(xiàn)問題后開始相互埋怨。放棄探索最佳實踐方法：磨刀不誤砍柴工，最佳實踐方法可以事半功倍。然而長期高強度工作會逐漸放棄花時間去“磨刀”。57開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響Defect大量增加：持續(xù)加班開發(fā)管理障礙列表在敏捷項目管理中的意義

及時將團隊的注意力引導向最重要的問題。集思廣益。由團隊成員一起討論解決，而不是由傳統(tǒng)意義上的項目經(jīng)理獨自來協(xié)調(diào)與分配。提高團隊的自主性。與風險管理結(jié)合，對即將或已經(jīng)發(fā)生的風險采取積極的應對態(tài)度。58開發(fā)管理障礙列表在敏捷項目管理中的意義

及時將團隊的注意力引開發(fā)管理團隊激勵59開發(fā)管理團隊激勵59開發(fā)管理團隊階段回顧60開發(fā)管理團隊階段回顧60開發(fā)管理

什么是激勵

激勵=活力+指引+堅持61開發(fā)管理

什么是激勵

激勵=活力+指引+堅持6開發(fā)管理什么是團隊–討論：一群個體與一個團隊的區(qū)別

一群個體避免交流與沖突自我中心低投入被動工作一個團隊彼此信任有共同目標開誠布公互相幫助有原則有樂趣團結(jié)積極交流傾向于解決問題62開發(fā)管理什么是團隊–討論：一群個體與一個團隊的區(qū)別

一群個體開發(fā)管理

團隊績效曲線

63開發(fā)管理

團隊績效曲線

63開發(fā)管理開發(fā)

詳細設計\開發(fā)\單元測試為專業(yè)開發(fā)開發(fā)時間

任務<=兩周；版本>=2周<=2月；這是一種健康節(jié)奏,不能經(jīng)常加班。最佳開發(fā)實踐

可持續(xù)開發(fā)節(jié)奏、團隊激勵、障礙列表、持續(xù)集成、產(chǎn)品燃盡圖、Sprint燃盡圖任務分配時間分配任務時按規(guī)劃時間/1.2計算。如規(guī)劃10天，10/1.2=8天，則安排8天完成，以保留時間貯備

在分配任務時1、以需求為主線（一個部分的需求、設計、開發(fā)、測試由一個人完成）2、以健康節(jié)奏（按120/100原則分配，具體因人而異3、任務分配在兩周之內(nèi)4、版本控制在兩個月內(nèi)5、行動之前落實承諾

開發(fā)主管在分配任務時1、選：勝任力2、定：定好目標，獲得承諾3、育：培訓4、用：定好績效（工作節(jié)奏）5、留：獎懲（按績效）總結(jié)

64開發(fā)管理開發(fā)詳細設計\開發(fā)\單元測試為專業(yè)測試管理

測試管理06665測試管理測試管理06665測試管理

測試測試的目的在于：核實對象之間的交互。核實軟件的所有構(gòu)件是否正確集成。核實所有需求是否已經(jīng)正確實施。確定缺陷并確保在部署軟件之前將缺陷解決。66測試管理測試測試的目的在于：核實對象之間的交互。核實軟件的測試管理1

軟件工程與測試模型

不同的開發(fā)模式適配不同的測試模型和測試過程。開發(fā)流水線產(chǎn)品平臺技術(shù)平臺規(guī)劃需求設計實現(xiàn)測試部署測試需求測試設計測試執(zhí)行測試執(zhí)行67測試管理1軟件工程與測試模型不同的開發(fā)模式適配不同的測試測試管理1.1

測試模型1：瀑布模型瀑布模型的核心思想是按工序?qū)栴}化簡，將功能的實現(xiàn)與設計分開，采用結(jié)構(gòu)化的分析與設計方法將邏輯實現(xiàn)與物理實現(xiàn)分開。軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試、運行維護。規(guī)定活動自上而下、相互銜接的固定次序，逐級下落。68測試管理1.1測試模型1：瀑布模型瀑布模型的核心思想是按工測試管理1.2測試模型2：V模型V模型是最廣為人知的測試模型由PaulRook在2０世紀８０年代后期提出的，旨在改進軟件開發(fā)的效率和效果。從左到右，描述了基本的開發(fā)過程和測試行為非常明確地標明了測試過程中存在的不同級別，描述了這些測試階段和開發(fā)過程期間各階段的對應關系69測試管理1.2測試模型2：V模型V模型是最廣為人知的測試模型測試管理1.3

測試模型3：W模型測試伴隨整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，測試與開發(fā)是同步進行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。測試和開發(fā)活動也保持著一種線性的前后關系，上一階段完全結(jié)束，才可正式開始下一個階段工作。這樣就無法很好的支持迭代開發(fā)。70測試管理1.3測試模型3：W模型測試伴隨整個軟件開發(fā)周期，測試管理1.4

測試模型4：X模型很好地處理測試與開發(fā)的交接過程（交接的過程是一個時間段，而不是一個點）左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，給有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件缺陷。71測試管理1.4測試模型4：X模型很好地處理測試與開發(fā)的交接測試管理2測試組織產(chǎn)品組/產(chǎn)品線測試組開發(fā)組項目1項目2項目3優(yōu)勢：1、與業(yè)務結(jié)合緊密（用例）；2、與代碼結(jié)合緊密（白盒）；缺點：1、測試資源未統(tǒng)一動態(tài)調(diào)配，使用有浪費；2、測試技能的統(tǒng)一提升和培訓少。72測試管理2測試組織產(chǎn)品組/產(chǎn)品線測試組開發(fā)組項目1項目2項測試管理2測試組織規(guī)模73測試管理2測試組織規(guī)模73測試管理2走向成熟：組織成熟怎么算組織成熟？74測試管理2走向成熟：組織成熟怎么算組織成熟？74測試管理2走向成熟：技術(shù)成熟：工具平臺75測試管理2走向成熟：技術(shù)成熟：工具平臺75測試管理2走向成熟：技術(shù)成熟：測試流水線業(yè)務知識76測試管理2走向成熟：技術(shù)成熟：測試流水線業(yè)務知識76測試管理2走向成熟：技術(shù)成熟：持續(xù)交付77測試管理2走向成熟：技術(shù)成熟：持續(xù)交付77測試管理3測試的過程管理：端到端測試過程總體測試要約測試準備測試計劃與方案測試設計測試分析與報告測試執(zhí)行78測試管理3測試的過程管理：端到端測試過程總體測試準備測試計測試管理3測試要約確定測試的總體范圍和目標確定總體測試時間計劃確定測試人員安排及組織結(jié)構(gòu)確定對應角色工作職責確定測試組運作機制確定主要測試流程79測試管理3測試要約確定測試的總體范圍和目標確定總體測試管理3總體測試要約：確定測試總流程80測試管理3總體測試要約：確定測試總流程80測試管理3.測試總體要約：bug類型與界定1.Bug嚴重程度；2.Bug分類；3.Bug修改的優(yōu)先級；4.Bug狀態(tài)81測試管理3.測試總體要約：bug類型與界定81測試管理3總體測試要約：確定與用戶的bug流程(上線&運維)客戶投訴內(nèi)部自查系統(tǒng)BUG業(yè)務規(guī)則易操作性操作過程BUG管理系統(tǒng)BUG問題列表BUG專題會公司級系統(tǒng)運營評估電話會議前臺操作員工程師客戶經(jīng)理每日問題反饋和解決（每日下午3:00）系統(tǒng)運行情況評估分析（每日下午5:30）現(xiàn)場派駐響應安排技術(shù)人員到現(xiàn)場，接收現(xiàn)場咨詢，現(xiàn)場無法解決時，提交到省公司問題處理組，省公司問題處理組安排相關人員進行解決。24小時熱線電話支持主要是針對緊急問題，快速提供解決問題的方法82測試管理3總體測試要約：確定與用戶的bug流程(上線&運維基礎管理3總體測試要約：確定測試的范圍和目標(舉例)

測試分類測試范圍覆蓋交付目標1功能測試(含單元/集成/接口/報表/測試)1）覆蓋全部網(wǎng)元/動作，支持各種業(yè)務；

2）覆蓋所有接口和報表；

3）覆蓋所有產(chǎn)品無關的功能點；1、業(yè)務覆蓋率100%；

2、接口連通性100%；

3、C類以上Bug修復率100%；2模擬測試渠道為營業(yè)廳辦理的業(yè)務模擬測試通過率95%；3性能測試覆蓋70%的業(yè)務量的主要業(yè)務；主要業(yè)務響應時間高于規(guī)范標準；資源使用合理；4安全性/兼容性測試主要業(yè)務抽取5種，覆蓋身份驗證、權(quán)限操作、密碼安全；覆蓋IE6、7、8及vista、xp、win7；安全性、兼容性用例通過率100%5容錯性測試雙機備份、單點故障等通過率100%83基礎管理3總體測試要約：確定測試的范圍和目標(舉例)測試分測試管理3總體測試要約：確定總體測試時間計劃84測試管理3總體測試要約：確定總體測試時間計劃84基礎管理3總體測試要約：確定測試人員安排及組織結(jié)構(gòu)85基礎管理3總體測試要約：確定測試人員安排及組織結(jié)構(gòu)85測試管理4、測試度量與評估：

項目期間bug管理1.BUG統(tǒng)一錄入BUG管理平臺;2.每天實時統(tǒng)計各測試人員BUG提交情況；3.每日根據(jù)實時匯總的BUG跟蹤表統(tǒng)計BUG新增情況與積壓延期情況4.修改后的BUG要及時跟進測試5.每日進行BUG處理情況接口人會議86測試管理4、測試度量與評估：項目期間bug管理86配置管理87

配置管理07

787配置管理87配置管理07787配置管理內(nèi)容提要軟件配置管理的概念軟件配置管理計劃軟件配置標識變更管理版本管理配置審核配置狀態(tài)報告軟件配置管理工具88配置管理內(nèi)容提要軟件配置管理的概念88配置管理一、軟件配置管理的概念（一）軟件配置項的概念1、軟件配置項：配置管理的對象稱為軟件配置項。表1軟件配置項的分類、特征和舉例分類特征舉例環(huán)境類軟件開發(fā)環(huán)境及軟件維護環(huán)境編譯器、操作系統(tǒng)、編輯器、數(shù)據(jù)庫管理系統(tǒng)、開發(fā)工具（如測試工具）、項目管理工具、文檔編輯工具定義類需求分析及定義階段完成后得到的工作產(chǎn)品需求規(guī)格說明書、項目開發(fā)計劃、設計標準或設計準則、驗收測試計劃設計類設計階段結(jié)束后得到的產(chǎn)品系統(tǒng)設計規(guī)格說明、程序規(guī)格說明、數(shù)據(jù)庫設計、編碼標準、用戶界面標準、測試標準、系統(tǒng)測試計劃、用戶手冊編碼類編碼及單元測試后得到的工作產(chǎn)品源代碼、目標碼、單元測試數(shù)據(jù)及單元測試結(jié)果測試類系統(tǒng)測試完成后的工作產(chǎn)品系統(tǒng)測試數(shù)據(jù)、系統(tǒng)測試結(jié)果、操作手冊、安裝手冊維護類進入維護階段以后產(chǎn)生的工作產(chǎn)品以上任何需要變更的軟件配置項89配置管理一、軟件配置管理的概念（一）軟件配置項的概念分類特配置管理2、軟件配置

軟件配置是一個軟件產(chǎn)品在生存期各個階段的不同形式（記錄特定信息的不同媒體）和不同版本的程序、文檔及相關數(shù)據(jù)的集合，或者說是配置項的集合。初始系統(tǒng)機型1機型2機型n操作系統(tǒng)1操作系統(tǒng)2用戶1用戶2圖1不同用戶有自己的工作環(huán)境90配置管理2、軟件配置初始系統(tǒng)機型1機型2機型n操作系統(tǒng)1操作配置管理（二）軟件配置管理1、什么是軟件配置管理（1）ISO9000-3:1997配置管理是一個管理學科，它對配置項（包括軟件項）的開發(fā)和支持生存期給與技術(shù)上的和管理上的指導。配置管理的應用取決于項目的規(guī)模、復雜程度和風險大小。（2）W.Babich的解釋軟件配置管理能協(xié)調(diào)軟件開發(fā)，使混亂減到最小，目的是最有效的提高生產(chǎn)率。（3）GB/T11457:1995《軟件工程術(shù)語》國家標準

A.表示和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存期內(nèi)控制這些配置項的投放和更動，記錄并報告配置的狀態(tài)和更動要求，驗證配置項的完整性和正確性。

B.對下列工作進行技術(shù)和行動指導與監(jiān)督的一套規(guī)范：

——對配置項的功能特性和物理特性進行標識和文件編制工作；

——控制這些特性的更動情況；

——記錄并報告這些更動進行的處理和實現(xiàn)的狀態(tài)。91配置管理（二）軟件配置管理91配置管理2、軟件配置管理的任務——制定軟件配置管理計劃——確定配置標識規(guī)則——實施變更控制——報告配置狀態(tài)——進行配置審核——進行版本管理和發(fā)行管理92配置管理2、軟件配置管理的任務92配置管理二、軟件配置管理計劃配置管理計劃標準——IEEE828-19901．引言——配置管理計劃的目的、適應范圍、使用要求——項目概述——項目中需特別關注的配置管理問題和風險——軟件配置管理嚴格性要求的等級——限制和假設——術(shù)語——參考文件93配置管理二、軟件配置管理計劃配置管理計劃標準——IEEE配置管理2、軟件配置管理——配置管理的組織結(jié)構(gòu)——職責和權(quán)限——指令和方針——參照的規(guī)程（組織的規(guī)程或客戶的規(guī)程）——遵循的標準3、軟件配置管理活動——配置管理活動——變更管理和配置控制——配置狀態(tài)說明——配置審核——接口和子合同方控制94配置管理2、軟件配置管理94配置管理4、軟件配置管理進度安排——軟件配置管理重要事件的順序——軟件配置管理各項活動間的依賴關系5、軟件配置管理所需的資源——采用的工具——使用的設備——所需的培訓——對其他人員的要求6、軟件配置管理計劃的維護——維護的職責——計劃更新的條件和審批——計劃變更的交流和通報95配置管理4、軟件配置管理進度安排95配置管理三、軟件配置標識（一）確定配置項1、

系統(tǒng)規(guī)格說明2、軟件項目計劃3、軟件需求規(guī)格說明書a.圖形分析模型b.處理規(guī)格說明c.原型d.數(shù)學規(guī)格說明4．初步用戶手冊5．設計規(guī)格說明書a.數(shù)據(jù)設計描述b.體系結(jié)構(gòu)設計描述c.模塊設計描述d.接口設計描述e.對象描述（采用面向?qū)ο蠹夹g(shù)時）6．源代碼清單7、測試規(guī)格說明

a.測試計劃和步驟

b.測試用例和記錄的結(jié)果8、操作和安裝手冊9、可執(zhí)行程序

a.模塊可執(zhí)行代碼b.連接的模塊10、數(shù)據(jù)庫描述

a.模式和文件結(jié)構(gòu)

b.初始內(nèi)容11、聯(lián)機用戶手冊12、維護文檔

a.軟件問題報告

b.維護請求

c.工程變更指令13.軟件工程標準和規(guī)程96配置管理三、軟件配置標識（一）確定配置項7、測試規(guī)格說明9配置管理（二）配置項命名及其相關信息1、配置項命名。命名的基本要求：唯一性；可追溯性。例：CODE是根結(jié)點為PCL_TOOLS樹結(jié)構(gòu)的第六層結(jié)點，對其命名為：PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE

97配置管理（二）配置項命名及其相關信息

97配置管理2、配置項的相關標識信息每一配置項的有關信息：——組名——項名——項標識（文件名或命名規(guī)則）——版本編號規(guī)則——什么情況下納入控制之下，或——版本號——所遵循的變更控制規(guī)程98配置管理2、配置項的相關標識信息98配置管理3、配置庫記錄與配置相關的所有信息利用庫中的信息可評價變更的后果可利用庫中的信息查詢，例如：那些客戶已提取了某個特定的系統(tǒng)版本？運行一個給定的系統(tǒng)版本需要什么硬件和系統(tǒng)的哪些版本?一個系統(tǒng)到目前已生成了多少版本，何時生成的？如果某一特定的構(gòu)件變更了，會影響到系統(tǒng)的那些版本？一個特定的版本曾提出過那幾個變更請求？一個特定的版本有多少已報告的錯誤？99配置管理3、配置庫99配置管理三類庫配置庫（1）開發(fā)庫：存放開發(fā)過程中需要保留的各種信息，供開發(fā)人員個人專用。（2）受控庫：在軟件開發(fā)的某個階段工作結(jié)束時，將工作產(chǎn)品存入或?qū)⒂嘘P的信息存入。（3）產(chǎn)品庫：在開發(fā)的軟件產(chǎn)品完成系統(tǒng)測試之后，作為最終產(chǎn)品存入庫內(nèi)，等待交付用戶或現(xiàn)場安裝。100配置管理三類庫配置庫100配置管理4、配置基線基線是軟件生存期各開發(fā)階段末尾的特定點，也稱為里程碑。101配置管理4、配置基線基線是軟件生存期各開發(fā)階段末尾的特定點配置管理

三種常見基線

——功能基線在系統(tǒng)分析和軟件定義階段結(jié)束時，經(jīng)過正式評審和批準的系統(tǒng)設計規(guī)格說明中對被開發(fā)軟件系統(tǒng)的規(guī)格說明；經(jīng)過項目委托單位和項目承辦單位雙方簽字同意的協(xié)議書或合同中所規(guī)定的對被開發(fā)軟件系統(tǒng)的規(guī)格說明；由下級申請及上級同意或直接由上級下達的項目任務書中所規(guī)定的對待開發(fā)軟件系統(tǒng)的規(guī)格說明。

——分配基線在軟件需求分析階段結(jié)束時，經(jīng)正式評審和批準的軟件需求規(guī)格說明。

——產(chǎn)品基線在軟件組裝與系統(tǒng)測試階段技術(shù)時，經(jīng)正式評審和批準的有關所開發(fā)的軟件產(chǎn)品的全部配置項的規(guī)格說明。102配置管理三種常見基線102配置管理四、版本管理1、軟件版本：包含兩種不同含義（1）為滿足不同用戶的不同使用要求，如適用于不同運行環(huán)境或不同平臺的系列產(chǎn)品。（2）軟件產(chǎn)品投入使用以后，經(jīng)過一段時間運行提出了變更的要求，需要做較大的修正或糾錯，增強功能或提高性能。2、版本標識版本管理也稱版本控制。版本標識方法：（1）號碼版本標識（2）符號版本標識：把重要的版本屬性有選擇地給出。如：V1/VMS/DBServer103配置管理四、版本管理1、軟件版本：包含兩種不同含義103配置管理五、配置審核（一）什么是配置審核它是指對于存儲配置項及相關記錄的軟件基線庫的結(jié)構(gòu)、內(nèi)容和設施進行檢驗，其目的在于驗證基線是否符合描述基線的文檔。驗證包括：配置項的處理是否有背離初始的規(guī)格說明或已批準的變更請求的現(xiàn)象；是否保持了可追溯性。配置標識的準則是否得到了遵循；變更控制規(guī)程是否以遵循，變更記錄是否可供使用配置審核工作主要集中在兩個方面，即：功能配置審核——驗證配置項的實際功效是與其軟件需求一致的。物理配置審核——確定配置項符合預期的物理特性，即特定的媒體形式。104配置管理五、配置審核（一）什么是配置審核104配置管理（二）為什么要實施配置審核

確保軟件配置管理的有效性，不允許出現(xiàn)任何混亂現(xiàn)象。例如：——防止出現(xiàn)向用戶提交了不適合的產(chǎn)品，如交付了用戶手冊不 適當?shù)陌姹?；——發(fā)現(xiàn)不完善的實現(xiàn)，如開發(fā)出不符合初始規(guī)格說明或未按變 更請求實施變更；——找出各配置項間不匹配或不相容的現(xiàn)象；——確認配置項已在所要求質(zhì)量控制審查之后作為基線入庫保存；——確認記錄和文檔保持著可追溯性。105配置管理（二）為什么要實施配置審核105配置管理六、配置狀態(tài)報告（一）什么是配置狀態(tài)報告

1、配置狀態(tài)報告任務：有效的記錄和報告管理配置所需要的信息目的：及時、準確的給出軟件配置項的當前狀況，供相關人員了解，以加強配置管理工作。

2、需要跟蹤捕捉的狀態(tài)報告信息可以是：配置項的當前標識已交付軟件的配置變更請求或問題報告的狀態(tài)已獲準變更的狀態(tài)106配置管理六、配置狀態(tài)報告（一）什么是配置狀態(tài)報告106最佳實踐107

最佳實踐08

8107最佳實踐107最佳實踐088107最佳實踐軟件研發(fā)的管理實踐不同的項目需要不同的方法論，一個項目的最佳過程是這個項目所能負擔的最小過程?！狝listairCockburn108最佳實踐軟件研發(fā)的管理實踐108最佳實踐本章提綱1IBM-Rational業(yè)務驅(qū)動開發(fā)的過程管理2微軟公司的軟件開發(fā)過程模式3敏捷模型的軟件研發(fā)管理4面向構(gòu)件的軟件研發(fā)5軟件研發(fā)的自定義體系109最佳實踐本章提綱1IBM-Rational業(yè)務驅(qū)動開發(fā)的最佳實踐敏捷模型的軟件研發(fā)管理1敏捷方法的過程模型2敏捷過程的最佳實踐110最佳實踐敏捷模型的軟件研發(fā)管理1敏捷方法的過程模型110最佳實踐敏捷方法的過程模型主張簡單、輕裝前進。擁抱變化，這種變化是不斷遞增的?？沙掷m(xù)性，簡單的說，在開發(fā)的時候就能想象到未來。項目投資產(chǎn)生最大的效益或回報。有目的的建模。多種模型。高質(zhì)量的工作、快速反饋。軟件是項目的主要目標，文檔是次要的。111最佳實踐敏捷方法的過程模型主張簡單、輕裝前進。111最佳實踐極限編程生命周期112最佳實踐極限編程生命周期112最佳實踐測試驅(qū)動開發(fā)113最佳實踐測試驅(qū)動開發(fā)113最佳實踐敏捷過程的最佳實踐編程簡單設計、測試、重構(gòu)、編碼標準團隊實踐代碼集體所有、持續(xù)集成、隱喻、編碼標準、每周40小時工作制、結(jié)對編程、小型發(fā)布過程現(xiàn)場客戶、測試、計劃博弈、小型發(fā)布起始階段細化階段構(gòu)建階段交付階段需求用戶素材小型發(fā)布先行測試測量分析CRC卡片迭代計劃任務計劃、迭代編程計劃博弈設計系統(tǒng)隱喻單元測試重構(gòu)持續(xù)集成實現(xiàn)編碼標準簡單設計集體代碼所有權(quán)運行所有測試114最佳實踐敏捷過程的最佳實踐編程簡單設計、測試、重構(gòu)、編碼標準最佳實踐面向構(gòu)件的軟件研發(fā)1面向構(gòu)件軟件研發(fā)的思想2面向構(gòu)件軟件研發(fā)的階段劃分115最佳實踐面向構(gòu)件的軟件研發(fā)1面向構(gòu)件軟件研發(fā)的思想115最佳實踐面向構(gòu)件軟件研發(fā)的思想1．從傳統(tǒng)的關注點分離到構(gòu)件組裝2．以構(gòu)件為中心組織軟件研發(fā)。3．高度關注可復用性和軟件研發(fā)知識積累4．高度并行的開發(fā)過程116最佳實踐面向構(gòu)件軟件研發(fā)的思想1．從傳統(tǒng)的關注點分離到構(gòu)件組最佳實踐基于構(gòu)件描述的網(wǎng)狀軟件結(jié)構(gòu)117最佳實踐基于構(gòu)件描述的網(wǎng)狀軟件結(jié)構(gòu)117最佳實踐面向構(gòu)件軟件研發(fā)的階段劃分需求階段。捕獲需求、識別業(yè)務構(gòu)件、歸納業(yè)務構(gòu)件需求。分析與高層設計階段。分析業(yè)務構(gòu)件、識別服務構(gòu)件，歸納服務構(gòu)件的需求并完成架構(gòu)設計。并行開發(fā)與測試階段。提交、發(fā)布與部署階段。應用管理。118最佳實踐面向構(gòu)件軟件研發(fā)的階段劃分需求階段。捕獲需求、識別業(yè)提問與解答環(huán)節(jié)Questionsandanswers提問與解答環(huán)節(jié)119結(jié)束語

感謝參與本課程，也感激大家對我們工作的支持與積極的參與。課程后會發(fā)放課程滿意度評估表，如果對我們課程或者工作有什么建議和意見，也請寫在上邊結(jié)束語

120軟件研發(fā)項目管理2013-2-20軟件研發(fā)項目管理2013-2-20標題添加點擊此處輸入相關文本內(nèi)容點擊此處輸入相關文本內(nèi)容前言點擊此處輸入相關文本內(nèi)容標題添加點擊此處輸入相關文本內(nèi)容標題添加點擊此處輸入相點擊此處輸入前言點擊此處輸入標題添加點122研發(fā)項目管理基礎1計劃管理2需求管理3設計管理4開發(fā)管理5測試管理6目錄配置管理7最佳實踐8123研發(fā)項目管理基礎1計劃管理2需求管理3設計管理4開發(fā)管理5測

基礎管理01

1124基礎管理0113總綱與規(guī)范六為法需求必為準團隊必為本計劃必為綱績效必為證質(zhì)量必為出變化必為形125總綱與規(guī)范六為法需求必為準4總綱與規(guī)范七定法兵馬未動、合約先行（定需求）可行的做可行事（定技術(shù)方案）謀定而后動（定計劃）專業(yè)的人做專業(yè)的事（定人員）溝通無止境、共識促發(fā)展（定共識）死亡之地不可不察也（定風險）應對隨形、修道保法（定變更）126總綱與規(guī)范七定法兵馬未動、合約先行（定需求）5總綱與規(guī)范三出路以正合（用人之術(shù)，諸如選育用留）以曲制（規(guī)律之術(shù)，諸如過程方法）以奇勝（變化之術(shù)，諸如動靜之理）127總綱與規(guī)范三出路以正合（用人之術(shù)，諸如選育用留）6總綱與規(guī)范兵法一曰道目的二曰天制度三曰地需求四曰將專業(yè)角色五曰法過程128總綱與規(guī)范兵法一曰道目的7基礎管理----過程管理過程的簡單描述129基礎管理----過程管理過程的簡單描述8基礎管理----過程管理軟件研發(fā)的分類和組成軟件基本過程：軟件獲取、供應、開發(fā)、運行和維護的過程，包括需求分析、軟件設計、編碼等過程。軟件支持過程：對軟件主要過程提供支持的過程，包括文檔編制過程、配置管理過程、質(zhì)量保證過程、驗證和確認過程（測試過程）、評審過程等。軟件組織過程：對軟件主要過程和支持過程的組織保證過程，包括管理過程、基礎設施過程、改進過程和培訓過程。130基礎管理----過程管理軟件研發(fā)的分類和組成軟件基本過程：軟基礎管理----過程管理ISO/IEC15504軟件生存周期過程131基礎管理----過程管理ISO/IEC15504軟件生存周期基礎管理----過程規(guī)范軟件研發(fā)規(guī)范的建立軟件能力成熟度模型（CMM/CMMI）IBM-Rtaional統(tǒng)一過程（RUP）極限編程（eXtremeProgramming，XP）微軟軟件框架（MSF）132基礎管理----過程規(guī)范軟件研發(fā)規(guī)范的建立軟件能力成熟度模型基礎管理----過程規(guī)范瀑布模型螺旋模型、增量模型、迭代模型V模型并發(fā)過程模型極限編程（XP）IBM-Rational統(tǒng)一過程（RUP）軟件研發(fā)模型133基礎管理----過程規(guī)范瀑布模型軟件研發(fā)模型12基礎管理----過程規(guī)范不是好的東西都能用，適用的才是最好的!需要我們根據(jù)自己人員的水平、公司情況、業(yè)務狀況綜合確定適合自己的研發(fā)過程134基礎管理----過程規(guī)范不是好的東西都能用，13基礎管理135

計劃管理02

2135基礎管理14計劃管理02214計劃管理軟件研發(fā)的項目管理有效的項目管理是在用來實現(xiàn)項目具體目標的規(guī)定時間內(nèi)，對組織機構(gòu)資源進行計劃、引導和控制工作?！俄椖抗芾碇R指南》136計劃管理軟件研發(fā)的項目管理15計劃管理WBS：

項目計劃形成之前，最好先畫WBS表（WorkBreakdownStructure），主要原理是：將任務逐級分解直至個人，在矩陣中體現(xiàn)為：先確定橫向有多少結(jié)點，再將每一結(jié)點任務逐漸細化直到個人，工作分解圖（WBS）實際上就是將一個復雜的開發(fā)系統(tǒng)分層逐步細化為一個個工作任務單元，這樣可以使我們將復雜、龐大的、不知如何下手的大系統(tǒng)劃分成了一個個獨立的我們能預測、計劃和控制的單元，從而也就達到了對整個系統(tǒng)進行控制的目的。137計劃管理WBS：項目計劃形成之前，最好先畫WBS表（WBS-工作分解結(jié)構(gòu)1項目范圍規(guī)劃

1.1 確定項目范圍

1.2 獲得項目所需資金

1.3 定義預備資源

1.4 獲得核心資源

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

2.1 行為需求分析

2.2 起草初步的軟件規(guī)范

2.3 制定初步預算

2.4 工作組共同審閱軟件規(guī)范/預算

2.5 根據(jù)反饋修改軟件規(guī)范

2.6 確定交付期限

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

2.9 分析工作完成3設計

3.1 審閱初步的軟件規(guī)范

3.2 制定功能規(guī)范

3.3 根據(jù)功能規(guī)范開發(fā)原型

3.4 審閱功能規(guī)范

3.5 根據(jù)反饋修改功能規(guī)范

3.6 獲得開展后續(xù)工作的批準

3.7 設計工作完成4開發(fā)

4.1 審閱功能規(guī)范

4.2 確定模塊化/分層設計參數(shù)

4.3 分派任務給開發(fā)人員

4.4 編寫代碼

4.5 開發(fā)人員測試(初步調(diào)試)4.6 開發(fā)工作完畢……計劃管理138WBS-工作分解結(jié)構(gòu)1項目范圍規(guī)劃 計劃管理17計劃管理創(chuàng)建WBS的基本法則每個工作工作單元在WBS只能出現(xiàn)一次概要任務是對其下所有任務的總結(jié)每個WBS的條目都有單獨的人員負責與實際要做的工作情形保持一致建立WBS時應讓項目組員參予每個WBS條目都應備案WBS既要靈活又要不失控制139計劃管理創(chuàng)建WBS的基本法則每個工作工作單元在WBS只能出現(xiàn)計劃管理項目估算令人煩惱的項目估算：這個項目需要多長時間？這個模塊大概多久完成？需要花費多少人力才能完成這個項目？項目的總成本大概為多少？

……140計劃管理項目估算令人煩惱的項目估算：19計劃管理項目成本的組成1.項目成本的組成（1）直接成本人力成本硬件設備軟件費用（2）間接成本項目管理成本一般管理成本141計劃管理項目成本的組成1.項目成本的組成20計劃管理責任矩陣用距陣的形式列出對某項任務負責的人或資源。任務管理人員項目經(jīng)理分析人員項目范圍規(guī)劃1.1確定項目范圍A1.2獲得項目所需資金A1.3定義預備資源A1.4獲得核心資源A分析/軟件需求2.1行為需求分析A2.2起草初步的軟件規(guī)范A2.3制定初步預算A2.4工作組共同審閱軟件規(guī)范/預算AP2.5根據(jù)反饋修改軟件規(guī)范A2.6確定交付期限A2.7獲得開展后續(xù)工作的批準AP2.8獲得所需資源A142計劃管理責任矩陣用距陣的形式列出對某項任務負責的人或資源。任計劃管理項目軟硬件資源管理1.軟件資源管理操作系統(tǒng)編譯器應用軟件測試工具……2.硬件資源管理服務器PC……143計劃管理項目軟硬件資源管理1.軟件資源管理22計劃管理10種常見的風險No.軟件風險相應對策1人員不足錄用優(yōu)秀人才；人員應適應崗位需要；全面考慮團隊建設；骨干人員工作要協(xié)調(diào)；實施培訓；預先安排關鍵人員的使用計劃2進度計劃和預算不準確詳細評估多種資源成本和進度；依成本進行設計；采用漸增式開發(fā)；軟件復用；純凈需求3開發(fā)了錯誤的軟件功能進行組織分析；實施任務分析；進行用戶調(diào)查；開發(fā)原型；及早編制用戶手冊4開發(fā)了不適用的用戶接口開發(fā)原型；制作腳本；作業(yè)分析；弄清了用戶特征(功能性、風格、工作負荷)5只追求表面效果，需求中含有一些不必要的功能（鍍金）純凈需求；開發(fā)原型；成本－效益分析；依成本進行設計6需求不斷變更重大變更設限；信息隱蔽；漸進式開發(fā)7外供部件不足制定基準點；檢驗；參考基準檢查；兼容性分析8外包任務問題參考基準檢查；發(fā)包前審核；未發(fā)包合同；競標設計或開發(fā)原型；建立團隊9實時性能達不到要求模擬；制定基準；建模；開發(fā)原型；安裝測量裝置；調(diào)準10誤解計算機科學能力技術(shù)分析；成本－效益分析；開發(fā)原型；參考基準檢查144計劃管理10種常見的風險No.軟件風險相應對策1人員不足錄用計劃管理項目跟蹤和控制1.了解成員的工作情況2.調(diào)整工作安排，合理利用資源3.促進計劃內(nèi)容的完善4.促進項目經(jīng)理對人員的認識5.促進對項目工作量的估計6.統(tǒng)計并了解項目總體進度7.有利于人員考核145計劃管理項目跟蹤和控制1.了解成員的工作情況24計劃管理現(xiàn)代軟件研發(fā)項目管理路線圖概覽146計劃管理現(xiàn)代軟件研發(fā)項目管理路線圖概覽25計劃管理項目預算與成本1、項目成本=直接成本*2.5直接成本為prj中的成本2、項目工期=基本工期+（悲觀時間-樂觀時間）/63、項目工期較長，可以分解為多個項目，每個項目不超過6個月，6個月內(nèi)按兩周做計劃。4、任務分解一般兩周:過粗不利分配工作,過細不利于人員的主動性.5、要識別任務關鍵路徑,根據(jù)人員情況并行或串行。147計劃管理項目預算與成本1、項目成本=直接成本*2.5直接成計劃管理WBSCHart148計劃管理WBSCHart27計劃管理ChartEXPERT149計劃管理ChartEXPERT28計劃管理關鍵路徑實例-Microsoftproject150計劃管理關鍵路徑實例-Microsoftproject需求管理151

需求管理033151需求管理30需求管理03330需求管理軟件研發(fā)的需求管理開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么?！ダ椎吕锟恕げ剪斂怂?52需求管理軟件研發(fā)的需求管理31需求管理軟件需求工程

所有與需求直接相關的活動統(tǒng)稱為需求工程，需求工程分為了兩個部分：需求開發(fā)和需求管理。其中，需求開發(fā)又分為了需求獲取、需求分析、需求定義和需求驗證4個部分，而需求管理則包含了變更控制、版本控制、需求跟蹤和需求狀態(tài)跟蹤

軟件需求包括三個不同的層次：業(yè)務需求、用戶需求和功能需求（也包括非功能需求）。153需求管理軟件需求工程所有與需求直接相關的活動需求管理軟件需求工程

業(yè)務需求（businessrequirement）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品的概括的目標要求，它在項目視圖與范圍文檔中予以說明。主要的目的是對企業(yè)目前的業(yè)務流程進行評估，得出一個業(yè)務前景。業(yè)務需求的確定對后面的用戶需求和功能需求起到了限制作用。

用戶需求(userrequirement)文檔描述了用戶使用系統(tǒng)而完成的任務的集合，用戶需求在用戶案例（usercase）文檔或方案腳本中予以說明。收集和分析用戶需求是不容易的，因為很多需求是隱形的，很難獲取，更難保證需求完整，而需求又是易變的，這就要求用戶和開發(fā)人員進行充分地交流。軟件需求(fsoftwarerequirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，它源于用戶需求。功能需求是軟件需求說明書中最重要的部分之一，它在開發(fā)、測試、質(zhì)量保證、項目管理以及相關項目功能中都起了重要的作用。非功能需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，包括要遵從的業(yè)務規(guī)則、人機接口、安全性和可靠性等要求。154需求管理軟件需求工程業(yè)務需求（businessrequi需求管理需求開發(fā)需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。獲取數(shù)據(jù)分析、處理目標系統(tǒng)模型需求獲取系統(tǒng)分析員從數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)出發(fā)，找出系統(tǒng)各元素之間的聯(lián)系、接口特征及設計限制、能否滿足功能需求155需求管理需求開發(fā)需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求需求管理需求獲取的方法需求研討會頭腦風暴用例模型訪談角色扮演原型法156需求管理需求獲取的方法需求研討會35需求管理基于用例的需求獲取執(zhí)行者的識別誰使用系統(tǒng)的主要功能？誰將提供、使用和刪除信息？誰負責維護、管理并保持系統(tǒng)正常運行？誰會對某一特定需求感興趣？系統(tǒng)的外部資源是什么？系統(tǒng)需要和哪些外部系統(tǒng)交互？用例的識別某個執(zhí)行者要求系統(tǒng)為其提供什么功能？該執(zhí)行者需要做哪些工作？執(zhí)行者需要閱讀、創(chuàng)建、銷毀、更新或存儲系統(tǒng)中哪些（類）信息？系統(tǒng)中的事件一定要告之執(zhí)行者嗎？執(zhí)行者需要告訴系統(tǒng)一些什么嗎？那些系統(tǒng)內(nèi)部的事件從功能的角度代表什么？由于新功能的識別，執(zhí)行者的日常工作被簡化或效率提高了嗎？系統(tǒng)需要什么樣的輸入輸出？輸入在哪里？輸出去往哪里？該系統(tǒng)的當前情況存在哪些問題？157需求管理基于用例的需求獲取36需求管理需求確認為什么需要需求評審？在哪個階段發(fā)現(xiàn)成本率需求1設計3-6編碼10功能測試15-40驗收測試30-70發(fā)布之后40-1000修訂一個缺陷的相關成本158需求管理需求確認為什么需要需求評審？在哪個階段發(fā)現(xiàn)成本率需求基礎管理需求跟蹤需求的標識<需求類型><需求#>需求類型可以是：F=功能需求，D=數(shù)據(jù)需求，B=行為需求，I=接口需求；O=輸出需求。

例：需求標識為F03的需求表示編號為3的功能需求。159基礎管理需求跟蹤需求的標識例：需求標識為F03的需求表示編號基礎管理160基礎管理39設計管理161

設計管理04

4161設計管理40設計管理04440設計管理架構(gòu)開發(fā)方法162設計管理架構(gòu)開發(fā)方法41設計管理架構(gòu)開發(fā)方法163設計管理架構(gòu)開發(fā)方法42設計管理架構(gòu)開發(fā)方法164設計管理架構(gòu)開發(fā)方法43設計管理架構(gòu)是軟件的基石架構(gòu)是軟件的基礎，一個良好的架構(gòu)可以讓軟件有更長久的生命力，能發(fā)揮出更出色的性能；架構(gòu)師要求對業(yè)務有深入的了解，這樣才能讓架構(gòu)更符合軟件的需要，更能發(fā)揮軟件的特點。165設計管理架構(gòu)是軟件的基石架構(gòu)是軟件的基礎，一個良好的架構(gòu)可以設計管理166設計管理45設計管理167設計管理46設計管理168設計管理47設計管理169設計管理48開發(fā)管理

開發(fā)管理055170開發(fā)管理開發(fā)管理05549開發(fā)管理1.開發(fā)開發(fā)的目的包括：對照開發(fā)子系統(tǒng)的分層結(jié)構(gòu)定義代碼結(jié)構(gòu);以構(gòu)件（源文件、二進制文件、可執(zhí)行文件以及其他文件等）的方式開發(fā)類和對象;對已開發(fā)的構(gòu)件按單元來測試;將各開發(fā)員（或團隊）完成的結(jié)果集成到可執(zhí)行系統(tǒng)中。171開發(fā)管理1.開發(fā)開發(fā)的目的包括：對照開發(fā)子系統(tǒng)的分層結(jié)構(gòu)定開發(fā)管理2.過程策略里程碑：最初操作性能最初操作性能里程碑確定產(chǎn)品是否已經(jīng)可以部署到Beta測試環(huán)境。在最初操作性能里程碑，產(chǎn)品隨時可以移交給產(chǎn)品化團隊。此時，已開發(fā)了所有功能，并完成了所有Alpha測試（如果有測試）。除了軟件之外，用戶手冊也已經(jīng)完成，而且有對當前發(fā)布版的說明。評估標準該產(chǎn)品發(fā)布版是否足夠穩(wěn)定和成熟，可部署在用戶群中？是否已準備好將產(chǎn)品發(fā)布到用戶群？實際的資源耗費與計劃的相比是否仍可以接受？如果項目無法達到該里程碑，產(chǎn)品化可能要推遲一個發(fā)布版。172開發(fā)管理2.過程策略里程碑：最初操作性能最初操作性能里程碑確開發(fā)管理最佳開發(fā)實踐新概念與最佳實踐可持續(xù)開發(fā)節(jié)奏團隊激勵障礙列表持續(xù)集成產(chǎn)品燃盡圖Sprint燃盡圖173開發(fā)管理最佳開發(fā)實踐新概念與最佳實踐52開發(fā)管理

可持續(xù)開發(fā)節(jié)奏的相關概念

可持續(xù)的開發(fā)節(jié)奏是一個開發(fā)團隊可長期（可以認為是永久）保持的開發(fā)節(jié)奏為了保持可持續(xù)的開發(fā)節(jié)奏，適當?shù)男菁倏梢宰寛F隊及時恢復精力。可持續(xù)的開發(fā)節(jié)奏并非禁止加班，但必須是偶然事件而非經(jīng)常性事件174開發(fā)管理

可持續(xù)開發(fā)節(jié)奏的相關概念

可持續(xù)的開發(fā)節(jié)奏是一個開開發(fā)管理討論當項目進度對于完成當前的迭代目標面臨壓力時，作為ScrumMaster，你會采取以下哪種方式？175開發(fā)管理討論當項目進度對于完成當前的迭代目標面臨壓力時，作為開發(fā)管理ScrumMaster要關注團隊的健康

高強度的開發(fā)節(jié)奏如果超過了團隊可承受的范圍，必然影響團隊的健康（包括心理和生理健康）。ScrumMaster應該關注團隊的健康狀況。選擇可持續(xù)的開發(fā)節(jié)奏，應該以團隊能夠感覺舒適地完成迭代目標為前提。176開發(fā)管理ScrumMaster要關注團隊的健康

高強度的開開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響177開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響56開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響Defect大量增加：持續(xù)加班狀況下代碼質(zhì)量很難保證，必然導致defect數(shù)量增加。工作效率降低：研究表明，當人疲勞時工作效率將急劇下降。團隊士氣低下：長期的高強度工作必然使團隊身心疲憊，士氣低落。開始相互推諉責任：長期高負荷工作下，導致出現(xiàn)問題后開始相互埋怨。放棄探索最佳實踐方法：磨刀不誤砍柴工，最佳實踐方法可以事半功倍。然而長期高強度工作會逐漸放棄花時間去“磨刀”。178開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響Defect大量增加：持續(xù)加班開發(fā)管理障礙列表在敏捷項目管理中的意義

及時將團隊的注意力引導向最重要的問題。集思廣益。由團隊成員一起討論解決，而不是由傳統(tǒng)意義上的項目經(jīng)理獨自來協(xié)調(diào)與分配。提高團隊的自主性。與風險管理結(jié)合，對即將或已經(jīng)發(fā)生的風險采取積極的應對態(tài)度。179開發(fā)管理障礙列表在敏捷項目管理中的意義

及時將團隊的注意力引開發(fā)管理團隊激勵180開發(fā)管理團隊激勵59開發(fā)管理團隊階段回顧181開發(fā)管理團隊階段回顧60開發(fā)管理

什么是激勵

激勵=活力+指引+堅持182開發(fā)管理

什么是激勵

激勵=活力+指引+堅持6開發(fā)管理什么是團隊–討論：一群個體與一個團隊的區(qū)別

一群個體避免交流與沖突自我中心低投入被動工作一個團隊彼此信任有共同目標開誠布公互相幫助有原則有樂趣團結(jié)積極交流傾向于解決問題183開發(fā)管理什么是團隊–討論：一群個體與一個團隊的區(qū)別

一群個體開發(fā)管理

團隊績效曲線

184開發(fā)管理

團隊績效曲線

63開發(fā)管理開發(fā)

詳細設計\開發(fā)\單元測試為專業(yè)開發(fā)開發(fā)時間

任務<=兩周；版本>=2周<=2月；這是一種健康節(jié)奏,不能經(jīng)常加班。最佳開發(fā)實踐

可持續(xù)開發(fā)節(jié)奏、團隊激勵、障礙列表、持續(xù)集成、產(chǎn)品燃盡圖、Sprint燃盡圖任務分配時間分配任務時按規(guī)劃時間/1.2計算。如規(guī)劃10天，10/1.2=8天，則安排8天完成，以保留時間貯備

在分配任務時1、以需求為主線（一個部分的需求、設計、開發(fā)、測試由一個人完成）2、以健康節(jié)奏（按120/100原則分配，具體因人而異3、任務分配在兩周之內(nèi)4、版本控制在兩個月內(nèi)5、行動之前落實承諾

開發(fā)主管在分配任務時1、選：勝任力2、定：定好目標，獲得承諾3、育：培訓4、用：定好績效（工作節(jié)奏）5、留：獎懲（按績效）總結(jié)

185開發(fā)管理開發(fā)詳細設計\開發(fā)\單元測試為專業(yè)測試管理

測試管理066186測試管理測試管理06665測試管理

測試測試的目的在于：核實對象之間的交互。核實軟件的所有構(gòu)件是否正確集成。核實所有需求是否已經(jīng)正確實施。確定缺陷并確保在部署軟件之前將缺陷解決。187測試管理測試測試的目的在于：核實對象之間的交互。核實軟件的測試管理1

軟件工程與測試模型

不同的開發(fā)模式適配不同的測試模型和測試過程。開發(fā)流水線產(chǎn)品平臺技術(shù)平臺規(guī)劃需求設計實現(xiàn)測試部署測試需求測試設計測試執(zhí)行測試執(zhí)行188測試管理1軟件工程與測試模型不同的開發(fā)模式適配不同的測試測試管理1.1

測試模型1：瀑布模型瀑布模型的核心思想是按工序?qū)栴}化簡，將功能的實現(xiàn)與設計分開，采用結(jié)構(gòu)化的分析與設計方法將邏輯實現(xiàn)與物理實現(xiàn)分開。軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試、運行維護。規(guī)定活動自上而下、相互銜接的固定次序，逐級下落。189測試管理1.1測試模型1：瀑布模型瀑布模型的核心思想是按工測試管理1.2測試模型2：V模型V模型是最廣為人知的測試模型由PaulRook在2０世紀８０年代后期提出的，旨在改進軟件開發(fā)的效率和效果。從左到右，描述了基本的開發(fā)過程和測試行為非常明確地標明了測試過程中存在的不同級別，描述了這些測試階段和開發(fā)過程期間各階段的對應關系190測試管理1.2測試模型2：V模型V模型是最廣為人知的測試模型測試管理1.3

測試模型3：W模型測試伴隨整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，測試與開發(fā)是同步進行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。測試和開發(fā)活動也保持著一種線性的前后關系，上一階段完全結(jié)束，才可正式開始下一個階段工作。這樣就無法很好的支持迭代開發(fā)。191測試管理1.3測試模型3：W模型測試伴隨整個軟件開發(fā)周期，測試管理1.4

測試模型4：X模型很好地處理測試與開發(fā)的交接過程（交接的過程是一個時間段，而不是一個點）左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，給有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件缺陷。192測試管理1.4測試模型4：X模型很好地處理測試與開發(fā)的交接測試管理2測試組織產(chǎn)品組/產(chǎn)品線測試組開發(fā)組項目1項目2項目3優(yōu)勢：1、與業(yè)務結(jié)合緊密（用例）；2、與代碼結(jié)合緊密（白盒）；缺點：1、測試資源未統(tǒng)一動態(tài)調(diào)配，使用有浪費；2、測試技能的統(tǒng)一提升和培訓少。193測試管理2測試組織產(chǎn)品組/產(chǎn)品線測試組開發(fā)組項目1項目2項測試管理2測試組織規(guī)模194測試管理2測試組織規(guī)模73測試管理2走向成熟：組織成熟怎么算組織成熟？195測試管理2走向成熟：組織成熟怎么算組織成熟？74測試管理2走向成熟：技術(shù)成熟：工具平臺196測試管理2走向成熟：技術(shù)成熟：工具平臺75測試管理2走