【導讀】被人們奉為軟件質(zhì)量管理圣經(jīng)的CMM和ISO9001似乎并不奏效，現(xiàn)實和理想之間的差距太大。經(jīng)典軟件工程教科書以及CMM和ISO9001總是拋開商業(yè)目標談質(zhì)量管理，本末倒置，紙上談兵，誤導了大量讀者，所以質(zhì)量管理才變得那么艱辛。要多向有實戰(zhàn)經(jīng)驗的同行專家請教，但是不要輕信“紙上談兵”的專家。本文給出了一套實用主義的“全面軟件質(zhì)量管理”方法。提高軟件質(zhì)量的最終目的是為了贏利，而不是創(chuàng)造完美無。因此對于普通商業(yè)軟件而言，并不是“質(zhì)量越高越好”，而是恰好讓廣大用戶滿意，并且將提高質(zhì)量所付出的代價控制在預算之內(nèi)。；③優(yōu)良或出色的程度。CMM對質(zhì)量的定義是：①一個系統(tǒng)、組件或過程符合特定需求的程度；②一個系統(tǒng)、組件或過。程符合客戶或用戶的要求或期望的程度。方面的生理因素來判斷是否健康，如測量身高、體重、心跳、血壓、血液、體溫等。上述因素都合格，那么表明這人是健康的。不健康，醫(yī)生會對癥下藥。技術(shù)評審和測試的第一關(guān)都是檢查工作成果的正確性。

　　

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