【正文】 原始問題可能很復(fù)雜，但高水平的人就能夠把軟件系統(tǒng)設(shè)計得很簡潔。這世界似乎不存在絕對安全的系統(tǒng)，連美國軍方的系統(tǒng)都頻頻遭黑客入侵。 – 如果軟件規(guī)模很大，問題很復(fù)雜，倘若軟件的可擴展性不好，那么該軟件就像用卡片造成的房子，抽出或者塞進(jìn)去一張卡片都有可能使房子倒塌。 ? 兼容性的商業(yè)規(guī)則：弱者設(shè)法與強者兼容，否則無容身之地；強者應(yīng)當(dāng)避免被兼容，否則市場將被瓜分。這是因為，不同的硬件體系結(jié)構(gòu)（例如 Intel CPU和 SPARC CPU） 使用不同的指令集和字長，而 OS和編譯器可以屏蔽這種差異，所以高級語言的可移植性更好。許多軟件人員都有 “ 質(zhì)量越高越好 ” 的觀念，這是被教科書灌輸?shù)?，而不是他自己領(lǐng)悟出來的。 Page 14 3. 商業(yè)目標(biāo)決定質(zhì)量目標(biāo) 普通商業(yè)軟件：商業(yè)目標(biāo)決定質(zhì)量目標(biāo) ? 上述嚴(yán)格系統(tǒng)畢竟是少數(shù) ， 絕大多數(shù)普通軟件的缺陷并不會造成機毀人亡這樣的重大損失 ， 否則沒有人敢從事軟件開發(fā)了 。 它包括評審和審核軟件產(chǎn)品及其活動 ， 以驗證其是否遵守既定的規(guī)程和標(biāo)準(zhǔn) ， 并向有關(guān)負(fù)責(zé)人匯報評審和審核的結(jié)果 。 ? 質(zhì)量保證的技術(shù)含量太低了，只能檢查出膚淺的缺陷，不能對付有技術(shù)難度的缺陷。 因為他們的過程執(zhí)行得很好 ， 這個項目可是通過 CMM3級正式評估了的 。所以說 “ 質(zhì)量保證并不能保證質(zhì)量 ” ，這句話一點都不過分。 郁悶的共同特征有： – （ 1） 在執(zhí)行質(zhì)量保證活動時 ， 經(jīng)常受別人的氣 ， 真是吃力不討好 。 平心而論 ， 他們比某些技術(shù)出色但是情商不高的技術(shù)人員更值得交朋友 。 任何素質(zhì)合格的員工都是寶貴的人才，很多默默無聞的人才其實是被不懂得質(zhì)量管理的領(lǐng)導(dǎo)給荒廢了。 Page 19 5. 質(zhì)量人員的狀況 贊美詩 ? 中國遭受 了非典型肺炎 （ SARS） 的肆虐 ， 人們在危難之際想起了醫(yī)護(hù)人員的好處 ， 因此涌現(xiàn)了許多對醫(yī)護(hù)人員的贊美詩 。 沒有他， 又怎會創(chuàng)造萬物的光芒。我大哥不外出治病 ， 他深知人們生病的原因 ， 所以能夠預(yù)防家里人生病 ， 他的醫(yī)術(shù)只有我們家里才知道 。 – 當(dāng)工作成果剛剛產(chǎn)生時馬上進(jìn)行質(zhì)量檢查，及時找出并消除工作成果中的缺陷。 Page 22 6. 全面軟件質(zhì)量管理：模型 模型 ? 借鑒老大、老二治病的方法，我們提煉出全面軟件質(zhì)量管理的模型，如下圖所示。 Page 24 7. 全面軟件質(zhì)量管理：制定質(zhì)量管理計劃 ? 質(zhì)量管理計劃就是為了實現(xiàn)質(zhì)量目標(biāo)的計劃。 ? 技術(shù)評審的主要好處有： – 通過消除工作成果的缺陷而提高產(chǎn)品的質(zhì)量； – 技術(shù)評審可以在任何開發(fā)階段執(zhí)行 ， 不必等到軟件可以運行之際 ， 越早消除缺陷就越能降低開發(fā)成本； – 開發(fā)人員能夠及時地得到同行專家的幫助和指導(dǎo) ， 無疑會加深對工作成果的理解 ， 更好地預(yù)防缺陷 ， 一定程度上提高了開發(fā)生產(chǎn)率 。 ? 在制定質(zhì)量計劃的時候，已經(jīng)確定了本項目的主要測試活動、時間和負(fù)責(zé)人，之后再考慮軟件測試的詳細(xì)計劃和測試用例。 ? 雖然本章批判了 “ 質(zhì)量保證 ” 的浮夸，但是并沒有全盤否定質(zhì)量保證的好處。 ? 質(zhì)量人員在執(zhí)行過程檢查的時候 ， 如果發(fā)現(xiàn)問題 ， 應(yīng)該立即記錄下來 。 ? 缺陷的主要屬性：缺陷 ID, 缺陷類型 ,缺陷狀態(tài) ,缺陷描述 ,相關(guān)文件 ,嚴(yán)重性 ,優(yōu)先級 ,報告者 ,報告日期 ,接受者 ,解決方案 （ 建議 ） ,解決日期 。 Page 30 11. 全面軟件質(zhì)量管理：缺陷跟蹤工具 概念 ? 如果沒有缺陷跟蹤工具的話 ， 人們只好用紙張或文件去記錄缺陷 ， 不僅變更缺陷信息很麻煩 ， 而且難以共享信息 。如果質(zhì)量人員發(fā)現(xiàn)開發(fā)人員寫的文檔與機構(gòu)的模板差異非常大，那么就要搞清楚究竟是模板不合適？還是開發(fā)人員偷工減料？ ? 過程檢查的要點是：找出明顯不符合規(guī)范的工作過程和工作成果，及時指導(dǎo)開發(fā)人員糾正問題，切勿吹毛求疵或者在無關(guān)痛癢的地方查來查去。 ? 請參考軟件測試的專題，此處省略。 ITR的形式比較靈活 ， 通常在同伴之間開展 ， 不必舉行評審會議， 評審人員比較少 。 ? 誰制定質(zhì)量管理計劃 ？ 由項目核心成員和質(zhì)量人員共同協(xié)商制定 ， 主要由質(zhì)量人員起草 ， 由項目經(jīng)理審批即可 。 所以人們不要把質(zhì)量問題全部推出質(zhì)量人員或測試人員 ?？稍诂F(xiàn)實之中，大多數(shù)軟件企業(yè)采用老三的方式來對付質(zhì)量問題。主要措施是 “ 不斷地提高技術(shù)水平，不斷地提高規(guī)范化水平 ” ，其實就是練內(nèi)功，通稱為 “ 軟件過程改進(jìn) ” 。缺陷越多質(zhì)量越低，缺陷越少質(zhì)量越高，提高軟件質(zhì)量的基本手段是消除軟件缺陷。 晚上八九點鐘的太陽 —獻(xiàn)給軟件測試和質(zhì)保人員 我更喜愛晚上八九點鐘的太陽， 雖然人們都已把他遺忘， 但他還是艱難地懸掛在天上。 – （ 3） 如果想讓質(zhì)量人員負(fù)起比較重的責(zé)任 ， 那么就要給她相應(yīng)的權(quán)力 。這樣下去，有能耐的質(zhì)量人員會跑光的。 – （ 4） 待遇一般 ， 看不到升遷的機會 ， 沒有盼頭 ， 要么成為打雜的 ， 要么另尋出路 。 而且我現(xiàn)在手頭有 5個項目要跟蹤 ， 還不包括一些整理培訓(xùn)記錄的雜活 ， 我覺得自己連工人也不如 。 而在做技術(shù)評審的時候 ， 他們很少能找出邏輯性的錯誤 ， 只能發(fā)現(xiàn)一些諸如錯別字之類的小錯誤 。 公司宣稱 ， 我們的軟件質(zhì)量大大提高了 ， 但是我卻沒有信心 。如此簡單的活動為什么被冠以 “ 質(zhì)量保證 ” 這等份量的術(shù)語呢？沒有歷史典故，經(jīng)我考究，猜想是源于一個天真的假設(shè)： – 過程質(zhì)量與產(chǎn)品質(zhì)量存在某種程度的因果關(guān)系，通常“好的過程”產(chǎn)生“好的產(chǎn)品”，而“差的過程”將產(chǎn)生“差的產(chǎn)品”。 但是企業(yè)不可能為了追求完美的質(zhì)量而不惜一切代價 ， 當(dāng)企業(yè)為提高質(zhì)量所付出的代價超過銷售收益時 ， 這個產(chǎn)品已經(jīng)沒有商業(yè)價值了 ， 還不如不開發(fā) 。 嚴(yán)格系統(tǒng)對質(zhì)量的要求 ? 航空航天等系統(tǒng)對質(zhì)量要求極高 ， 任何缺陷都有可能導(dǎo)致機毀人亡 ， 所以人們不惜一切代價去消除缺陷 。 Page 13 3. 商業(yè)目標(biāo)決定質(zhì)量目標(biāo) 教科書的片面觀點 ? 大凡軟件工程教科書為了強調(diào)質(zhì)量的重要性，總是要舉一些歷史上發(fā)生過的重大軟件質(zhì)量事故，例如航天飛機爆炸、核電站失事、愛國者導(dǎo)彈發(fā)生故障等等。但是 Word絕對不會與 WPS兼容，除非 WPS又在中國稱老大。 ? 談到軟件的可擴展性，開發(fā)人員首先想到的是怎樣提高可擴展性，于是努力去設(shè)計很好的體系結(jié)構(gòu)來提高可擴展性，卻不考慮該不該做這件事。 Page 11 2. 軟件質(zhì)量屬性和質(zhì)量要素 可擴展性 ? 可擴展性反映軟件適應(yīng) “ 變化 ” 的能力。 ? 千萬不要把在學(xué)校里 “ 造文章 ” 的手法用于開發(fā)產(chǎn)品！ – 如果把文章寫得很簡潔，讓人很容易理解，投稿往往中不了；只有加上一些玄乎的東西，把本來簡單的弄成復(fù)雜的，才會增加投稿的命中率。當(dāng)用戶真的感到軟件很好用時，一股溫暖的感覺油然而生，于是就用 “ 界面友好 ”