軟件研發(fā)項目管理2013-2-201研發(fā)項目管理基礎(chǔ)1計劃管理2需求管理3設(shè)計管理4開發(fā)管理5測試管理6目錄配置管理7最佳實踐82

基礎(chǔ)管理01

13總綱與規(guī)范六為法需求必為準(zhǔn)團(tuán)隊必為本計劃必為綱績效必為證質(zhì)量必為出變化必為形4總綱與規(guī)范七定法兵馬未動、合約先行（定需求）可行的做可行事（定技術(shù)方案）謀定而后動（定計劃）專業(yè)的人做專業(yè)的事（定人員）溝通無止境、共識促發(fā)展（定共識）死亡之地不可不察也（定風(fēng)險）應(yīng)對隨形、修道保法（定變更）5總綱與規(guī)范三出路以正合（用人之術(shù)，諸如選育用留）以曲制（規(guī)律之術(shù)，諸如過程方法）以奇勝（變化之術(shù)，諸如動靜之理）6總綱與規(guī)范兵法一曰道

目的二曰天

制度三曰地

需求四曰將

專業(yè)角色五曰法

過程7基礎(chǔ)管理----過程管理過程的簡單描述8基礎(chǔ)管理----過程管理軟件研發(fā)的分類和組成軟件基本過程：軟件獲取、供應(yīng)、開發(fā)、運(yùn)行和維護(hù)的過程，包括需求分析、軟件設(shè)計、編碼等過程。軟件支持過程：對軟件主要過程提供支持的過程，包括文檔編制過程、配置管理過程、質(zhì)量保證過程、驗證和確認(rèn)過程（測試過程）、評審過程等。軟件組織過程：對軟件主要過程和支持過程的組織保證過程，包括管理過程、基礎(chǔ)設(shè)施過程、改進(jìn)過程和培訓(xùn)過程。9基礎(chǔ)管理----過程管理ISO/IEC15504軟件生存周期過程10基礎(chǔ)管理----過程規(guī)范軟件研發(fā)規(guī)范的建立軟件能力成熟度模型（CMM/CMMI）IBM-Rtaional統(tǒng)一過程（RUP）極限編程（eXtremeProgramming，XP）微軟軟件框架（MSF）11基礎(chǔ)管理----過程規(guī)范瀑布模型螺旋模型、增量模型、迭代模型V模型并發(fā)過程模型極限編程（XP）IBM-Rational統(tǒng)一過程（RUP）軟件研發(fā)模型12基礎(chǔ)管理----過程規(guī)范不是好的東西都能用，適用的才是最好的!需要我們根據(jù)自己人員的水平、公司情況、業(yè)務(wù)狀況綜合確定適合自己的研發(fā)過程13基礎(chǔ)管理13

計劃管理02

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

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

1.1 確定項目范圍

1.2 獲得項目所需資金

1.3 定義預(yù)備資源

1.4 獲得核心資源

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

2.1 行為需求分析

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

2.3 制定初步預(yù)算

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

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

2.6 確定交付期限

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

2.9 分析工作完成3設(shè)計

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

3.2 制定功能規(guī)范

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

3.4 審閱功能規(guī)范

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

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

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

4.1 審閱功能規(guī)范

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

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

4.4 編寫代碼

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

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

需求管理03330需求管理軟件研發(fā)的需求管理開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么。——弗雷德里克·布魯克斯31需求管理軟件需求工程

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

軟件需求包括三個不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）。32需求管理軟件需求工程

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

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

例：需求標(biāo)識為F03的需求表示編號為3的功能需求。38基礎(chǔ)管理39設(shè)計管理39

設(shè)計管理04

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

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

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

可持續(xù)的開發(fā)節(jié)奏是一個開發(fā)團(tuán)隊可長期（可以認(rèn)為是永久）保持的開發(fā)節(jié)奏為了保持可持續(xù)的開發(fā)節(jié)奏，適當(dāng)?shù)男菁倏梢宰寛F(tuán)隊及時恢復(fù)精力?？沙掷m(xù)的開發(fā)節(jié)奏并非禁止加班，但必須是偶然事件而非經(jīng)常性事件53開發(fā)管理討論當(dāng)項目進(jìn)度對于完成當(dāng)前的迭代目標(biāo)面臨壓力時，作為ScrumMaster，你會采取以下哪種方式？54開發(fā)管理ScrumMaster要關(guān)注團(tuán)隊的健康

高強(qiáng)度的開發(fā)節(jié)奏如果超過了團(tuán)隊可承受的范圍，必然影響團(tuán)隊的健康（包括心理和生理健康）。ScrumMaster應(yīng)該關(guān)注團(tuán)隊的健康狀況。選擇可持續(xù)的開發(fā)節(jié)奏，應(yīng)該以團(tuán)隊能夠感覺舒適地完成迭代目標(biāo)為前提。55開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響56開發(fā)管理不可持續(xù)開發(fā)節(jié)奏的影響Defect大量增加：持續(xù)加班狀況下代碼質(zhì)量很難保證，必然導(dǎo)致defect數(shù)量增加。工作效率降低：研究表明，當(dāng)人疲勞時工作效率將急劇下降。團(tuán)隊士氣低下：長期的高強(qiáng)度工作必然使團(tuán)隊身心疲憊，士氣低落。開始相互推諉責(zé)任：長期高負(fù)荷工作下，導(dǎo)致出現(xiàn)問題后開始相互埋怨。放棄探索最佳實踐方法：磨刀不誤砍柴工，最佳實踐方法可以事半功倍。然而長期高強(qiáng)度工作會逐漸放棄花時間去“磨刀”。57開發(fā)管理障礙列表在敏捷項目管理中的意義

及時將團(tuán)隊的注意力引導(dǎo)向最重要的問題。集思廣益。由團(tuán)隊成員一起討論解決，而不是由傳統(tǒng)意義上的項目經(jīng)理獨(dú)自來協(xié)調(diào)與分配。提高團(tuán)隊的自主性。與風(fēng)險管理結(jié)合，對即將或已經(jīng)發(fā)生的風(fēng)險采取積極的應(yīng)對態(tài)度。58開發(fā)管理團(tuán)隊激勵59開發(fā)管理團(tuán)隊階段回顧60開發(fā)管理

什么是激勵

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

一群個體避免交流與沖突自我中心低投入被動工作一個團(tuán)隊彼此信任有共同目標(biāo)開誠布公互相幫助有原則有樂趣團(tuán)結(jié)積極交流傾向于解決問題62開發(fā)管理

團(tuán)隊績效曲線

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

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

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

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

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

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

64測試管理

測試管理06665測試管理

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

軟件工程與測試模型

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

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

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

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

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

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

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

2、接口連通性100%；

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

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

配置管理07

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

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

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

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

——對配置項的功能特性和物理特性進(jìn)行標(biāo)識和文件編制工作；

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

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

系統(tǒng)規(guī)格說明2、軟件項目計劃3、軟件需求規(guī)格說明書a.圖形分析模型b.處理規(guī)格說明c.原型d.數(shù)學(xué)規(guī)格說明4．

初步用戶手冊5．設(shè)計規(guī)格說明書a.數(shù)據(jù)設(shè)計描述b.體系結(jié)構(gòu)設(shè)計描述c.模塊設(shè)計描述d.接口設(shè)計描述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)機(jī)用戶手冊12、維護(hù)文檔

a.軟件問題報告

b.維護(hù)請求

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

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

三種常見基線

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

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

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

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

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

2、需要跟蹤捕捉的狀態(tài)報告信息可以是：