【正文】 制定質(zhì)量計劃 （ 很重要但是工作量比較少 ） ； （ 2） 負責過程檢查 （ 類似于 CMM中的質(zhì)量保證 ） ， 約占個人工作量的20%； （ 3） 參與技術(shù)評審 ， 約占個人工作量的 30%； （ 4） 參與軟件測試 ， 約占個人工作量的 30%； （ 5） 參與軟件過程改進 （ 面向整個機構(gòu) ） ， 約占個人工作量的 20%； *上述工作量的比例僅供參考 ， 在實際應(yīng)用時必須根據(jù)項目的特征而定 。 Page 37 7. 全面軟件質(zhì)量管理：制定質(zhì)量管理計劃 ?質(zhì)量管理計劃就是為了實現(xiàn)質(zhì)量目標的計劃。而質(zhì)量目標則是由商業(yè)目標決定的。開發(fā)軟件產(chǎn)品的最終目的是為了賺錢，所以人們?yōu)樘岣哕浖|(zhì)量所付出的代價是有上限的，項目負責人當然希望代價越低越好。質(zhì)量管理計劃是全面質(zhì)量管理的行動綱領(lǐng)。 ?誰制定質(zhì)量管理計劃 ？ 由項目核心成員和質(zhì)量人員共同協(xié)商制定 ，主要由質(zhì)量人員起草 ， 由項目經(jīng)理審批即可 。 ?質(zhì)量管理計劃的主要內(nèi)容 （ 模板見 word文件 ） ： 1. 質(zhì)量要素分析 2. 質(zhì)量目標 3. 人員與職責 4. 過程檢查計劃 5. 技術(shù)評審計劃 6. 軟件測試計劃 7. 缺陷跟蹤工具 8. 審批意見 Page 38 8. 全面軟件質(zhì)量管理：技術(shù)評審 概念 ?技術(shù)評審 （ Technical Review, TR） 的目的是盡早地發(fā)現(xiàn)工作成果中的缺陷 ， 并幫助開發(fā)人員及時消除缺陷 ， 從而有效地提高產(chǎn)品的質(zhì)量 。 ?技術(shù)評審最初是由 IBM公司為了提高軟件質(zhì)量和提高程序員生產(chǎn)率而倡導的 。 技術(shù)評審方法已經(jīng)被業(yè)界廣泛采用并收到了很好的效果 ，它被普遍認為是軟件開發(fā)的最佳實踐之一 。 ?技術(shù)評審的主要好處有： ?通過消除工作成果的缺陷而提高產(chǎn)品的質(zhì)量； ?技術(shù)評審可以在任何開發(fā)階段執(zhí)行 ， 不必等到軟件可以運行之際 ， 越早消除缺陷就越能降低開發(fā)成本； ?開發(fā)人員能夠及時地得到同行專家的幫助和指導 ， 無疑會加深對工作成果的理解 ， 更好地預防缺陷 ， 一定程度上提高了開發(fā)生產(chǎn)率 。 Page 39 8. 全面軟件質(zhì)量管理：技術(shù)評審 概念 ?技術(shù)評審有兩種基本類型： ? 正式技術(shù)評審 （ FTR） 。 FTR比較嚴格 ， 需要舉行評審會議 ， 參加評審會議的人員比較多 。 ? 非正式技術(shù)評審 （ ITR） 。 ITR的形式比較靈活 ， 通常在同伴之間開展 ， 不必舉行評審會議 ， 評審人員比較少 。 Page 40 8. 全面軟件質(zhì)量管理：技術(shù)評審 正式技術(shù)評審的流程 技術(shù)評審報告的模板見 word文檔 Page 41 9. 全面軟件質(zhì)量管理：軟件測試 觀點 ?技術(shù)評審和軟件測試的目的都是為了消除軟件的缺陷，兩者的主要區(qū)別是： ?前者無需運行軟件，評審人員和作者把工作成果擺放在桌面上討論； ?而后者一定要運行軟件來查找缺陷。技術(shù)評審在軟件測試之前執(zhí)行，尤其是在需求開發(fā)和系統(tǒng)設(shè)計階段。 ?相比而言，軟件測試的工作量通常比技術(shù)評審的大，發(fā)現(xiàn)的缺陷也更多。 ?在制定質(zhì)量計劃的時候，已經(jīng)確定了本項目的主要測試活動、時間和負責人，之后再考慮軟件測試的詳細計劃和測試用例。 Page 42 9. 全面軟件質(zhì)量管理：軟件測試 觀點 ? 如果機構(gòu)沒有專職的軟件測試人員的話，那么開發(fā)人員可以兼職做測試工作。當項目開發(fā)到后期，過程檢查和技術(shù)評審都已經(jīng)沒有多少意義了，開發(fā)小組急需有人幫助他們測試軟件，如果質(zhì)量人員參與軟件測試，對開發(fā)小組而言簡直就是 “ 雪中送炭 ” 。 ? 強調(diào)：質(zhì)量人員一定要參與軟件測試（大約占其工作量的 30％左右），只有這樣他才能深入地了解軟件的質(zhì)量問題，而且給予開發(fā)小組強有力地幫助。 ? 請參考軟件測試的專題，此處省略。 Page 43 10. 全面軟件質(zhì)量管理：過程檢查 觀點 ?CMM和 ISO9001所述的軟件質(zhì)量保證 ， 實質(zhì)就是過程檢查 ， 即檢查軟件項目的 “ 工作過程和工作成果 ” 是否符合既定的規(guī)范 。 ?“ 過程檢查 ” 這個詞雖然沒有質(zhì)量保證那么動聽 ， 但是其含義直接明了 ， 不會讓人誤解 。 為了避免人們誤以為 “ 質(zhì)量保證 ” 能夠 “ 保證質(zhì)量 ” ， 我提議用 “ 過程檢查 ” 取代質(zhì)量保證這個術(shù)語 。 ?雖然本章批判了 “ 質(zhì)量保證 ” 的浮夸，但是并沒有全盤否定質(zhì)量保證的好處。過程檢查對提高軟件質(zhì)量是有幫助的，只是它的好處沒有象質(zhì)量保證鼓吹的那么好而已。 ?符合規(guī)范的工作成果不見得就是高質(zhì)量的，但是明顯不符合規(guī)范的工作成果十有八九是質(zhì)量不合格的。 ?例如版本控制檢查 ?再例如，機構(gòu)制定了重要工作成果的文檔模板（例如需求規(guī)格說明書、設(shè)計報告等），要求開發(fā)人員寫的文檔盡可能符合模板。如果質(zhì)量人員發(fā)現(xiàn)開發(fā)人員寫的文檔與機構(gòu)的模板差異非常大，那么就要搞清楚究竟是模板不合適？還是開發(fā)人員偷工減料？ Page 44 10. 全面 軟件質(zhì)量 管理：過程檢查 觀點 ? 過程檢查的要點是：找出明顯不符合規(guī)范的工作過程和工作成果，及時指導開發(fā)人員糾正問題，切勿吹毛求疵或者在無關(guān)痛癢的地方查來查去。 ? 不少機構(gòu)的質(zhì)量人員并沒有真正理解過程檢查的意義，老是對照規(guī)范，查找錯別字、標點符號、排版格式等問題，迷失了方向，這樣只有疲勞沒有功勞，而且讓開發(fā)人員很厭煩。 ? 對于中小型項目而言，過程檢查工作由質(zhì)量人員一個人負責就夠了，約占其 20％的工作量，讓質(zhì)量人員抽出更多的時間從事技術(shù)評審和軟件測試工作。 Page 45 10. 全面軟件質(zhì)量管理：過程檢查 流程 ?過程檢查計劃的要點是確定主要檢查項和檢查時間 （ 或頻度 ） 。 ?質(zhì)量人員在執(zhí)行過程檢查的時候 ， 如果發(fā)現(xiàn)問題 ， 應(yīng)該立即記錄下來 。 過程問題也是缺陷 ， 因此最好使用缺陷跟蹤工具 ， 有助于提高過程檢查的效率 。 ?質(zhì)量人員首先設(shè)法在項目內(nèi)部解決已經(jīng)發(fā)現(xiàn)的質(zhì)量問題 ， 與項目成員們協(xié)商 ， 給出解決措施 。 在項目內(nèi)難以解決的質(zhì)量問題 ， 由上級領(lǐng)導給出解決措施 。 Page 46 11. 全面軟件質(zhì)量管理：缺陷跟蹤工具 概念 ?如果沒有缺陷跟蹤工具的話 ， 人們只好用紙張或文件去記錄缺陷 ，不僅變更缺陷信息很麻煩 ， 而且難以共享信息 。 缺陷跟蹤工具就是幫助項目成員記錄和跟蹤缺陷用的 ， 一般都有數(shù)據(jù)庫支持 ， 可以在局域網(wǎng)內(nèi)運行 。 ?Inter上有許多缺陷跟蹤工具 ， 大家可以免費下載使用 。 由于缺陷跟蹤工具僅僅是一種輔助性的工具 ， 我們沒有必要太在乎該軟件的功能 ， 只要用起來方便就行 。 ?缺陷的主要屬性：缺陷 ID, 缺陷類型 ,缺陷狀態(tài) ,缺陷描述 ,相關(guān)文件 ,嚴重性 ,優(yōu)先級 ,報告者 ,報告日期 ,接受者 ,解決方案 （ 建議 ） ,解決日期 。 ?缺陷跟蹤工具的常見功能：查詢?nèi)毕?,添加缺陷 ,修改缺陷 ,刪除 ,缺陷分類圖 ,缺陷趨勢圖 , Email