【正文】 得很簡潔。 ? 千萬不要把在學(xué)校里 “ 造文章 ” 的手法用于開發(fā)產(chǎn)品！ 如果把文章寫得很簡潔，讓人很容易理解，投稿往往中不了；只有加上一些玄乎的東西，把本來簡單的弄成復(fù)雜的，才會增加投稿的命中率。這世界似乎不存在絕對安全的系統(tǒng)，連美國軍方的系統(tǒng)都頻頻遭黑客入侵。 Page 17 2. 軟件質(zhì)量屬性和質(zhì)量要素 可擴(kuò)展性 ?可擴(kuò)展性反映軟件適應(yīng) “ 變化 ” 的能力。 ?如果軟件規(guī)模很大，問題很復(fù)雜，倘若軟件的可擴(kuò)展性不好，那么該軟件就像用卡片造成的房子，抽出或者塞進(jìn)去一張卡片都有可能使房子倒塌。 ?談到軟件的可擴(kuò)展性，開發(fā)人員首先想到的是怎樣提高可擴(kuò)展性，于是努力去設(shè)計很好的體系結(jié)構(gòu)來提高可擴(kuò)展性，卻不考慮該不該做這件事。 ?兼容性的商業(yè)規(guī)則：弱者設(shè)法與強(qiáng)者兼容，否則無容身之地；強(qiáng)者應(yīng)當(dāng)避免被兼容，否則市場將被瓜分。但是 Word絕對不會與 WPS兼容，除非 WPS又在中國稱老大。這是因為，不同的硬件體系結(jié)構(gòu)（例如 Intel CPU和 SPARC CPU）使用不同的指令集和字長，而 OS和編譯器可以屏蔽這種差異，所以高級語言的可移植性更好。 Page 21 3. 商業(yè)目標(biāo)決定質(zhì)量目標(biāo) 教科書的片面觀點(diǎn) ?大凡軟件工程教科書為了強(qiáng)調(diào)質(zhì)量的重要性，總是要舉一些歷史上發(fā)生過的重大軟件質(zhì)量事故，例如航天飛機(jī)爆炸、核電站失事、愛國者導(dǎo)彈發(fā)生故障等等。許多軟件人員都有 “ 質(zhì)量越高越好 ” 的觀念，這是被教科書灌輸?shù)?，而不是他自己領(lǐng)悟出來的。 Page 22 3. 商業(yè)目標(biāo)決定質(zhì)量目標(biāo) 嚴(yán)格系統(tǒng)對質(zhì)量的要求 航空航天等系統(tǒng)對質(zhì)量要求極高 ， 任何缺陷都有可能導(dǎo)致機(jī)毀人亡 ，所以人們不惜一切代價去消除缺陷 。 Page 23 3. 商業(yè)目標(biāo)決定質(zhì)量目標(biāo) 普通商業(yè)軟件：商業(yè)目標(biāo)決定質(zhì)量目標(biāo) ?上述嚴(yán)格系統(tǒng)畢竟是少數(shù) ， 絕大多數(shù)普通軟件的缺陷并不會造成機(jī)毀人亡這樣的重大損失 ， 否則沒有人敢從事軟件開發(fā)了 。 但是企業(yè)不可能為了追求完美的質(zhì)量而不惜一切代價 ，當(dāng)企業(yè)為提高質(zhì)量所付出的代價超過銷售收益時 ， 這個產(chǎn)品已經(jīng)沒有商業(yè)價值了 ， 還不如不開發(fā) 。 它包括評審和審核軟件產(chǎn)品及其活動 ， 以驗證其是否遵守既定的規(guī)程和標(biāo)準(zhǔn) ， 并向有關(guān)負(fù)責(zé)人匯報評審和審核的結(jié)果 。如此簡單的活動為什么被冠以“質(zhì)量保證”這等份量的術(shù)語呢？沒有歷史典故，經(jīng)我考究，猜想是源于一個天真的假設(shè)： 過程質(zhì)量與產(chǎn)品質(zhì)量存在某種程度的因果關(guān)系，通?！昂玫倪^程”產(chǎn)生“好的產(chǎn)品”，而“差的過程”將產(chǎn)生“差的產(chǎn)品”。 ? 質(zhì)量保證的技術(shù)含量太低了，只能檢查出膚淺的缺陷，不能對付有技術(shù)難度的缺陷。 公司宣稱 ， 我們的軟件質(zhì)量大大提高了 ， 但是我卻沒有信心 。 因為他們的過程執(zhí)行得很好 ， 這個項目可是通過 CMM3級正式評估了的 。 而在做技術(shù)評審的時候 ， 他們很少能找出邏輯性的錯誤 ，只能發(fā)現(xiàn)一些諸如錯別字之類的小錯誤 。所以說 “ 質(zhì)量保證并不能保證質(zhì)量 ” ，這句話一點(diǎn)都不過分。 而且我現(xiàn)在手頭有 5個項目要跟蹤 ， 還不包括一些整理培訓(xùn)記錄的雜活 ， 我覺得自己連工人也不如 。 郁悶的共同特征有： （ 1） 在執(zhí)行質(zhì)量保證活動時 ， 經(jīng)常受別人的氣 ， 真是吃力不討好 。 （ 4） 待遇一般 ， 看不到升遷的機(jī)會 ， 沒有盼頭 ， 要么成為打雜的 ， 要么另尋出路 。 質(zhì)量檢查是他們的工作職責(zé) ， 誰也不會有意干擾項目 ， 所以任何人都不應(yīng)該向他們發(fā)火 。 我所認(rèn)識的多數(shù)質(zhì)量人員要么改行了（如當(dāng)老師），要么讀工程碩士， MBA等，以圖將來發(fā)展事業(yè)。質(zhì)量人員之所以沒有發(fā)揮預(yù)期的效果，不是性別緣故，主要過失在于領(lǐng)導(dǎo)者。 在企業(yè)中 ， 責(zé)任和權(quán)利是成正比的 。 ?我碰巧在網(wǎng)上搜索到一位軟件詩人獻(xiàn)給質(zhì)量人員的贊美詩 “ 晚上八九點(diǎn)鐘的太陽 ” ，我認(rèn)為沒有必要等到軟件質(zhì)量災(zāi)難降臨的時候才想起質(zhì)量人員，于是摘錄這首詩公布于此。 我更喜愛晚上八九點(diǎn)鐘的太陽， 因為他將奏出黎明的交響。 狼人望月嚎叫， 它知道 月亮映出的太陽之光， 終將化為銀彈， 射入它的胸膛。 ?中國郎中看病的故事 在中國古代 ， 有一家三兄弟全是郎中 。 ” ?郎中三兄弟是三種治病方式的代言人。 ?即使一個人嚴(yán)守養(yǎng)生之道 ， 身體狀況良好 ， 但總是會意外地得病的 ， 得了病就要去看醫(yī)生 。這種方式效果比較好，人們一般都能學(xué)會。典型現(xiàn)象是：在軟件交付之前，沒有及時消除缺陷。項目中的所有人員幾乎都參與了質(zhì)量活動，只是介入的程度不同而已，后面幾節(jié)將逐一介紹這些質(zhì)量活動。 ?誰對軟件質(zhì)量負(fù)最大的責(zé)任 ？ 誰的權(quán)利越大 ， 他所負(fù)的質(zhì)量責(zé)任就越大 。而質(zhì)量目標(biāo)則是由商業(yè)目標(biāo)決定的。 ?質(zhì)量管理計劃的主要內(nèi)容 （ 模板見 word文件 ） ： 1. 質(zhì)量要素分析 2. 質(zhì)量目標(biāo) 3. 人員與職責(zé) 4. 過程檢查計劃 5. 技術(shù)評審計劃 6. 軟件測試計劃 7. 缺陷跟蹤工具 8. 審批意見 Page 38 8. 全面軟件質(zhì)量管理：技術(shù)評審 概念 ?技術(shù)評審 （ Technical Review, TR） 的目的是盡早地發(fā)現(xiàn)工作成果中的缺陷 ， 并幫助開發(fā)人員及時消除缺陷 ， 從而有效地提高產(chǎn)品的質(zhì)量 。 Page 39 8. 全面軟件質(zhì)量管理：技術(shù)評審 概念 ?技術(shù)評審有兩種基本類型： ? 正式技術(shù)評審 （ FTR） 。 Page 40 8. 全面軟件質(zhì)量管理：技術(shù)評審 正式技術(shù)評審的流程 技術(shù)評審報告的模板見 word文檔 Page 41 9. 全面軟件質(zhì)量管理：軟件測試 觀點(diǎn) ?技術(shù)評審和軟件測試的目的都是為了消除軟件的缺陷，兩者的主要區(qū)別是： ?前者無需運(yùn)行軟件，評審人員和作者把工作成果擺放在桌面上討論； ?而后者一定要運(yùn)行軟件來查找缺陷。 Page 42 9. 全面軟件質(zhì)量管理：軟件測試 觀點(diǎn) ? 如果機(jī)構(gòu)沒有專職的軟件測試人員的話，那么開發(fā)人員可以兼職做測試工作。 Page 43 10. 全面軟件質(zhì)量管理：過程檢查 觀點(diǎn) ?CMM和 ISO9001所述的軟件質(zhì)量保證 ， 實質(zhì)就是過程檢查 ， 即檢查軟件項目的 “ 工作過程和工作成果 ” 是否符合既定的規(guī)范 。過程檢查對提高軟件質(zhì)量是有幫助的，只是它的好處沒有象質(zhì)量保證鼓吹的那么好而已。 ? 不少機(jī)構(gòu)的質(zhì)量人員并沒有真正理解過程檢查的意義，老是對照規(guī)范，查找錯別字、標(biāo)點(diǎn)符號、排版格式等問題，迷失了方向，這樣只有疲勞沒有功勞，而且讓開發(fā)人員很厭煩。 過程問題也是缺陷 ， 因此最好使用缺陷跟蹤工具 ， 有助于提高過程檢查的效率 。 缺陷跟蹤工具就是幫助項目成員記錄和跟蹤缺陷用的 ， 一般都有數(shù)據(jù)庫支持 ， 可以在局域網(wǎng)內(nèi)運(yùn)行 。 ?缺陷跟蹤工具的常見功能：查詢?nèi)毕?,添加缺陷 ,修改缺陷 ,刪除 ,缺陷分類圖 ,缺陷趨勢圖 , Email