【正文】 性 、 可測試性 、 可維護性 、 靈活性等 。 ? 用戶才不管正確性與健壯性的區(qū)別，反正軟件出了差錯都是開發(fā)方的錯。只要人們發(fā)現(xiàn)系統(tǒng)有毛病，便歸結(jié)為可靠性差。這種看法是不對的，殊不知隨著機器的升級，軟件系統(tǒng)也越來越龐大了和復(fù)雜了，性能優(yōu)化仍然大有必要。 ? 千萬不要把在學(xué)校里 “ 造文章 ” 的手法用于開發(fā)產(chǎn)品！ – 如果把文章寫得很簡潔，讓人很容易理解，投稿往往中不了；只有加上一些玄乎的東西，把本來簡單的弄成復(fù)雜的，才會增加投稿的命中率。 ? 談到軟件的可擴展性，開發(fā)人員首先想到的是怎樣提高可擴展性，于是努力去設(shè)計很好的體系結(jié)構(gòu)來提高可擴展性，卻不考慮該不該做這件事。 Page 13 3. 商業(yè)目標決定質(zhì)量目標 教科書的片面觀點 ? 大凡軟件工程教科書為了強調(diào)質(zhì)量的重要性，總是要舉一些歷史上發(fā)生過的重大軟件質(zhì)量事故，例如航天飛機爆炸、核電站失事、愛國者導(dǎo)彈發(fā)生故障等等。 但是企業(yè)不可能為了追求完美的質(zhì)量而不惜一切代價 ， 當(dāng)企業(yè)為提高質(zhì)量所付出的代價超過銷售收益時 ， 這個產(chǎn)品已經(jīng)沒有商業(yè)價值了 ， 還不如不開發(fā) 。 公司宣稱 ， 我們的軟件質(zhì)量大大提高了 ， 但是我卻沒有信心 。 而且我現(xiàn)在手頭有 5個項目要跟蹤 ， 還不包括一些整理培訓(xùn)記錄的雜活 ， 我覺得自己連工人也不如 。這樣下去，有能耐的質(zhì)量人員會跑光的。 晚上八九點鐘的太陽 —獻給軟件測試和質(zhì)保人員 我更喜愛晚上八九點鐘的太陽， 雖然人們都已把他遺忘， 但他還是艱難地懸掛在天上。主要措施是 “ 不斷地提高技術(shù)水平，不斷地提高規(guī)范化水平 ” ，其實就是練內(nèi)功，通稱為 “ 軟件過程改進 ” 。 所以人們不要把質(zhì)量問題全部推出質(zhì)量人員或測試人員 。 ITR的形式比較靈活 ， 通常在同伴之間開展 ， 不必舉行評審會議， 評審人員比較少 。如果質(zhì)量人員發(fā)現(xiàn)開發(fā)人員寫的文檔與機構(gòu)的模板差異非常大，那么就要搞清楚究竟是模板不合適？還是開發(fā)人員偷工減料？ ? 過程檢查的要點是：找出明顯不符合規(guī)范的工作過程和工作成果，及時指導(dǎo)開發(fā)人員糾正問題，切勿吹毛求疵或者在無關(guān)痛癢的地方查來查去。 ? 缺陷的主要屬性：缺陷 ID, 缺陷類型 ,缺陷狀態(tài) ,缺陷描述 ,相關(guān)文件 ,嚴重性 ,優(yōu)先級 ,報告者 ,報告日期 ,接受者 ,解決方案 （ 建議 ） ,解決日期 。 ? 雖然本章批判了 “ 質(zhì)量保證 ” 的浮夸，但是并沒有全盤否定質(zhì)量保證的好處。 ? 技術(shù)評審的主要好處有： – 通過消除工作成果的缺陷而提高產(chǎn)品的質(zhì)量； – 技術(shù)評審可以在任何開發(fā)階段執(zhí)行 ， 不必等到軟件可以運行之際 ， 越早消除缺陷就越能降低開發(fā)成本； – 開發(fā)人員能夠及時地得到同行專家的幫助和指導(dǎo) ， 無疑會加深對工作成果的理解 ， 更好地預(yù)防缺陷 ， 一定程度上提高了開發(fā)生產(chǎn)率 。 Page 22 6. 全面軟件質(zhì)量管理：模型 模型 ? 借鑒老大、老二治病的方法，我們提煉出全面軟件質(zhì)量管理的模型，如下圖所示。我大哥不外出治病 ， 他深知人們生病的原因 ， 所以能夠預(yù)防家里人生病 ， 他的醫(yī)術(shù)只有我們家里才知道 。 Page 19 5. 質(zhì)量人員的狀況 贊美詩 ? 中國遭受 了非典型肺炎 （ SARS） 的肆虐 ， 人們在危難之際想起了醫(yī)護人員的好處 ， 因此涌現(xiàn)了許多對醫(yī)護人員的贊美詩 。 平心而論 ， 他們比某些技術(shù)出色但是情商不高的技術(shù)人員更值得交朋友 。所以說 “ 質(zhì)量保證并不能保證質(zhì)量 ” ，這句話一點都不過分。 ? 質(zhì)量保證的技術(shù)含量太低了，只能檢查出膚淺的缺陷，不能對付有技術(shù)難度的缺陷。 Page 14 3. 商業(yè)目標決定質(zhì)量目標 普通商業(yè)軟件：商業(yè)目標決定質(zhì)量目標 ? 上述嚴格系統(tǒng)畢竟是少數(shù) ， 絕大多數(shù)普通軟件的缺陷并不會造成機毀人亡這樣的重大損失 ， 否則沒有人敢從事軟件開發(fā)了 。這是因為，不同的硬件體系結(jié)構(gòu)（例如 Intel CPU和 SPARC CPU） 使用不同的指令集和字長，而 OS和編譯器可以屏蔽這種差異，所以高級語言的可移植性更好。 – 如果軟件規(guī)模很大，問題很復(fù)雜，倘若軟件的可擴展性不好，那么該軟件就像用卡片造成的房子，抽出或者塞進去一張卡片都有可能使房子倒塌。一個原始問題可能很復(fù)雜，但高水平的人就能夠把軟件系統(tǒng)設(shè)計得很簡潔。例如數(shù)據(jù)庫程序的優(yōu)化?？墒俏覀儫o法對軟件進行徹底地測試，無法根除軟件中潛在的錯誤。 ? 機器不會主動欺騙人，軟件運行出錯通常都是人造成的，所以不要找借口埋怨機器有毛病。如果上述因素都合格，那么表明這人是健康的。全面軟件質(zhì)量管理 —— 剖析軟件質(zhì)量的內(nèi)涵 —— 內(nèi)建高質(zhì)量而非修補質(zhì)量 林 銳 博士 上 海 漫 索 計 算 機 科 技 有 限 公 司 Page 2 目錄 1. 引言 2. 軟件質(zhì)量屬性和質(zhì)量要素 3. 商業(yè)目標決定質(zhì)量目標 4. 質(zhì)量保證能夠保證質(zhì)量嗎 5. 質(zhì)量人員的狀況 6. 全面軟件質(zhì)量管理：模型 7. 全面軟件質(zhì)量管理：制定質(zhì)量計劃 8. 全面軟件質(zhì)量管理：技術(shù)評審 9. 全面軟件質(zhì)量管理：軟件測試 10. 全面軟件質(zhì)量管理：過程檢查 11. 全面軟件質(zhì)量管理：缺陷跟蹤工具 參考書：《軟件工程與項目管理解析》，林銳 著，電子工業(yè)出版社， 20xx Page 3 1. 引言 ? 軟件質(zhì)量管理是充滿爭論的話題。如果某個因素不合格，則表明此人在某個方面不健康，醫(yī)生會對癥下藥。 健壯性 ? 健壯性是指在異常情況下，軟件能夠正常運行的能力。平時軟件運行得好好的，說不準哪一天就不正常了，如有千年等一回的 “ 千年蟲 ” 問題，司空見慣的 “ 內(nèi)存泄露 ” 、 “ 誤差累積 ” 問題等等。 – 算法復(fù)雜度分析是很好的方法，可以達到 “ 未卜先知 ” 的功效。如果軟件系統(tǒng)臃腫不堪，它遲早會出問題。 ? 現(xiàn)代軟件產(chǎn)品通常采用 “ 增量開發(fā)模式 ” ，不斷推出新版本，獲取增值利潤。 – Java程序號稱 “ 一次編譯，到處運行 ” ，具有 100%的可移植性。 在日常工作中 ， 我們接觸過的軟件幾乎都是有缺陷的 ， 即便是軟件業(yè)老大 Microsoft， 它的軟件產(chǎn)品也經(jīng)常出錯甚至導(dǎo)致死機 ， 人們罵幾句后還會照樣使用有缺陷的軟件 。所以單獨的“ 質(zhì)量保證 ” 其實并不能 “ 保證質(zhì)量 ” 。 質(zhì)量保證對于保證質(zhì)量而言只是必要的手段，而不是充分的手段。 質(zhì)量檢查是他們的工作職責(zé) ， 誰也不會有意干擾項目 ， 所以任何人都不應(yīng)該向他們發(fā)火 。 ? 我碰巧在網(wǎng)上搜索到一位軟件詩人獻給質(zhì)量人員的贊美詩 “ 晚上八九點鐘的太陽 ” ，我認為沒有必要等到軟件質(zhì)量災(zāi)難降臨的時候才想起質(zhì)量人員，于是摘錄這首詩公布于此。 ” ? 郎中三兄弟是三種治病方式的代言人。項目中的所有人員幾乎都參與了質(zhì)量活動，只是介入的程度不同而已，后面幾節(jié)將逐