【正文】 問題。 由于軟件是“軟”的，是否它天生就容易修改以適應(yīng)“變化”？ 關(guān)鍵要看軟件的規(guī)模和復(fù)雜性 ?如果軟件規(guī)模很小，問題很簡單，那么修改起來的確比較容易，這時就無所謂 “ 可擴展性 ” 了。但是如果軟件永遠都不會有下個版本（一次性買賣），那么根本無需提高可擴展性，何必自找苦吃呢！ Page 19 2. 軟件質(zhì)量屬性和質(zhì)量要素 兼容性 ?兼容性是指不同產(chǎn)品（或者新老產(chǎn)品）相互交換信息的能力。（互聯(lián)網(wǎng)的價值與用戶數(shù)量的平方成正比） Page 20 2. 軟件質(zhì)量屬性和質(zhì)量要素 可移植性 ? 軟件的可移植性指的是軟件不經(jīng)修改或稍加修改就可以運行于不同軟硬件環(huán)境（ CPU、 OS和編譯器）的能力，主要體現(xiàn)為代碼的可移植性。 ?學(xué)術(shù)界總是喜歡宣揚質(zhì)量至上的理念，而忽視企業(yè)的商業(yè)利益，將質(zhì)量目標凌駕于商業(yè)目標之上。 前蘇聯(lián)做得最過分 ， 許多重大武器系統(tǒng)的負責(zé)人都簽了生死狀 ， 系統(tǒng)研制成功則獲得英雄勛章 ， 失敗則被槍斃 。 企業(yè)理想的質(zhì)量目標不是 “ 零缺陷 ” ， 而是恰好讓廣大用戶滿意 ， 并且將提高質(zhì)量所付出的代價控制在預(yù)算之內(nèi) 。反之，如果質(zhì)量保證人員沒有發(fā)現(xiàn)不符合既定規(guī)范的東西，那么也可以斷定產(chǎn)品是合格的。 今天還有一個項目經(jīng)理跟我訴苦：前一階段大家都忙于執(zhí)行過程 ， 但是他的產(chǎn)品質(zhì)量令人很不滿意 ， 尤其是測試做的很不到位 。 公司已經(jīng)通過 CMM3級了 ， 我認為過程執(zhí)行得很好了 ， 可是軟件質(zhì)量仍然比較差 。 ?郁悶的滋味各色各樣 ， 只有正在郁悶的人感受最真切 。 ? 我所認識的公司內(nèi)外的質(zhì)量人員都是性格溫和 、 細致耐心的人 ，他們的優(yōu)點在于人格而不是技術(shù) 。而質(zhì)量人員通常是女性，很多男性主管從未真正地把質(zhì)量人員當(dāng)成企業(yè)的寶貴人才看待，這種偏見是非常有害的。 （ 4）給質(zhì)量人員一個適宜的升遷機會和薪資待遇，讓她能夠快樂地工作，而不是成天無奈地檢查質(zhì)量。 沒有他 又怎會有什么希望？ 我更喜愛晚上八九點鐘的太陽， 因為他是上帝的臂膀。 我二哥通常在人們剛剛生病的時候馬上就治愈他們 ， 臨近村莊的人說他是好郎中 。 ?同理，在開發(fā)軟件的時候，即使人們的技術(shù)水平很高，并且嚴格遵守規(guī)范，但是人非機器，總是會犯錯誤的，因此無法完全避免軟件中的缺陷?？尚Φ氖?，當(dāng)軟件系統(tǒng)在用戶那里出故障了，那些現(xiàn)場補救成功的人倒成了英雄，好心用戶甚至還寄來感謝信。 ?質(zhì)量人員的主要職責(zé)： （ 1） 負責(zé)制定質(zhì)量計劃 （ 很重要但是工作量比較少 ） ； （ 2） 負責(zé)過程檢查 （ 類似于 CMM中的質(zhì)量保證 ） ， 約占個人工作量的20%； （ 3） 參與技術(shù)評審 ， 約占個人工作量的 30%； （ 4） 參與軟件測試 ， 約占個人工作量的 30%； （ 5） 參與軟件過程改進 （ 面向整個機構(gòu) ） ， 約占個人工作量的 20%； *上述工作量的比例僅供參考 ， 在實際應(yīng)用時必須根據(jù)項目的特征而定 。 技術(shù)評審方法已經(jīng)被業(yè)界廣泛采用并收到了很好的效果 ，它被普遍認為是軟件開發(fā)的最佳實踐之一 。 ?相比而言，軟件測試的工作量通常比技術(shù)評審的大，發(fā)現(xiàn)的缺陷也更多。 為了避免人們誤以為 “ 質(zhì)量保證 ” 能夠 “ 保證質(zhì)量 ” ， 我提議用 “ 過程檢查 ” 取代質(zhì)量保證這個術(shù)語 。 Page 45 10. 全面軟件質(zhì)量管理：過程檢查 流程 ?過程檢查計劃的要點是確定主要檢查項和檢查時間 （ 或頻度 ） 。 由于缺陷跟蹤工具僅僅是一種輔助性的工具 ， 我們沒有必要太在乎該軟件的功能 ， 只要用起來方便就行 。 在項目內(nèi)難以解決的質(zhì)量問題 ， 由上級領(lǐng)導(dǎo)給出解決措施 。 ?例如版本控制檢查 ?再例如，機構(gòu)制定了重要工作成果的文檔模板（例如需求規(guī)格說明書、設(shè)計報告等），要求開發(fā)人員寫的文檔盡可能符合模板。 ? 強調(diào)：質(zhì)量人員一定要參與軟件測試（大約占其工作量的 30％左右），只有這樣他才能深入地了解軟件的質(zhì)量問題，而且給予開發(fā)小組強有力地幫助。 ? 非正式技術(shù)評審 （ ITR） 。質(zhì)量管理計劃是全面質(zhì)量管理的行動綱領(lǐng)。 任何與軟件開發(fā) 、 管理工作相關(guān)的人員都對質(zhì)量產(chǎn)生影響 ， 都要對質(zhì)量負責(zé) 。 Page 34 6. 全面軟件質(zhì)量管理：模型 消除軟件缺陷的三種方式 ? 老三治病的方式代價最高，只能是不得已而為之。 提高軟件質(zhì)量最好的辦法是： 在開發(fā)過程中有效地防止工作成果產(chǎn)生缺陷，將高質(zhì)量內(nèi)建于開發(fā)過程之中。 Page 32 6. 全面軟件質(zhì)量管理：模型 郎中治病的故事 ?質(zhì)量的死對頭是缺陷（ defect,bug… ）， 缺陷是混在產(chǎn)品中的人們不喜歡、不想要的東西，它對產(chǎn)品沒有好處只有壞處。衷心感謝這位不知姓名的浪漫軟件詩人。 （ 2） 只有當(dāng)企業(yè)領(lǐng)導(dǎo)采用了正確的質(zhì)量管理方案 ， 用了合格的質(zhì)量人員 ， 才可能看得到比較明顯的質(zhì)量改善 ， 才能形成良性循環(huán) 。質(zhì)量人員通常僅給企業(yè)起到心里安慰的作用。 領(lǐng)導(dǎo)們嘴上重視產(chǎn)品的質(zhì)量 ， 但是內(nèi)心并不重視質(zhì)量人員 。 Page 27 5. 質(zhì)量人員的狀況 郁悶 ?QA人員訴苦： 我現(xiàn)在覺得很郁悶 ， CMM評估前還有目標 ， 評估完了冷靜下來卻覺得效果很差 ， 很沒勁 。但是對于我們公司而言 ， 它并沒有在根本上提高我們公司的軟件能力 。 Page 26 4. 質(zhì)量保證能夠保證質(zhì)量嗎 CMM3級企業(yè) QA人員的迷惘（ 摘錄） 我很迷茫 ， 很想找一個人聊聊 ， 希望你能給我點主意 ， 化解我心中的謎團 。 基于我親身實踐和調(diào)查研究 ， 我敢冒天下之大不諱說一句： 質(zhì)量保證并不能保證質(zhì)量 ， 它是個美麗的謊言 。 ?企業(yè)的根本目標是為了獲取盡可能多的利潤 ， 而不是生產(chǎn)完美無缺的產(chǎn)品 。 盡管此書得到了許多程序員的贊同 ， 但是我經(jīng)過反思之后改變了質(zhì)量觀念 ，我要著重指出的是： 重視軟件質(zhì)量是應(yīng)該的 ， 但是 “ 質(zhì)量越高越好 ” 并不是普適的真理 。為了提高 Java程序的性能，最新的 Java標準允許人們使用一些與平臺相關(guān)的優(yōu)化技術(shù)，這樣優(yōu)化后的 Java程序雖然不能 “ 一次編譯，到處運行 ” ，仍然能夠 “ 一次編程，到處編譯 ” 。 ?金山軟件公司的 WPS與微軟的 Word之爭。可擴展性越來越重要。 ?究竟什么樣的安全性是令人滿意的呢？ ?一般地，如果黑客為非法入侵花費的代價（考慮時間、費用、風(fēng)險等因素）高于得到的好處，那么這樣的系統(tǒng)可以認為是安全的。所以簡潔是人們對工作 “ 精益求精 ” 的結(jié)果，而不是潦草應(yīng)付的結(jié)果。 ?開發(fā)人員犯了 “ 錯位 ” 的毛?。核詾橹灰约河闷饋矸奖?，用戶也就會滿意。 Page 13 2. 軟件質(zhì)量屬性和質(zhì)量要素 性能 ? 性能優(yōu)化就好像從海綿里擠水一樣，你不擠，水就不出來，你越擠海綿越干。人們總希望軟件的運行速度高些，并且占用資源少些。 Page 11 2. 軟件質(zhì)量屬性和質(zhì)量要素 可靠性 ? 軟件