【正文】 、 “ 方便易用 ” 等詞來評價軟件產(chǎn)品。這種看法是不對的，殊不知隨著機器的升級，軟件系統(tǒng)也越來越龐大了和復雜了，性能優(yōu)化仍然大有必要。 ? 性能優(yōu)化的關(guān)鍵工作是找出限制性能的 “ 瓶頸 ” ，不要在無關(guān)痛癢的地方瞎忙乎。只要人們發(fā)現(xiàn)系統(tǒng)有毛病，便歸結(jié)為可靠性差。 ? 可靠性本來是硬件領(lǐng)域的術(shù)語。 ? 用戶才不管正確性與健壯性的區(qū)別，反正軟件出了差錯都是開發(fā)方的錯。 Page 6 2. 軟件質(zhì)量屬性和質(zhì)量要素 正確性 ? 正確性是指軟件按照需求正確執(zhí)行任務的能力。 ? 軟件的質(zhì)量屬性很多 ， 如正確性 、 精確性 ， 健壯性 、 可靠性 、 容錯性 、 性能 、 易用性 、 安全性 、可擴展性 、 可復用性 、 兼容性 、 可移植性 、 可測試性 、 可維護性 、 靈活性等 。 ? 上述定義很抽象，人們看了準會一臉迷惘。世界上還沒有萬能的軟件質(zhì)量管理圣經(jīng)，我們不要迷信 CMM和 ISO9000。 ? 要多向有實戰(zhàn)經(jīng)驗的同行專家請教，但是不要輕信 “ 紙上談兵 ” 的專家。就讓我們用 “ 人的健康 ” 來類比解釋軟件質(zhì)量。 ? 上述這些質(zhì)量屬性之間 “ 你中有我 ， 我中有他 ” ， 非常纏綿 。 “ 正確性 ” 的語義涵蓋了 “ 精確性 ” 。所以提高軟件的健壯性也是開發(fā)者的義務。比如某個電子設(shè)備在剛開始工作時挺好的，但由于器件在工作中其物理性質(zhì)會發(fā)生變化（如發(fā)熱），慢慢地系統(tǒng)的功能或性能就會失常。從專業(yè)角度講，這種說法是確切的。 – 例如在大學里當教師，光靠使勁講課或者埋頭做實驗，職稱是升不快的。 – 最具有代表性的是三維游戲軟件，例如《 Delta Force》、《 古墓麗影》、《反恐精英》等，如果不對軟件（關(guān)鍵是游戲引擎）做精益求精的優(yōu)化，要想在一臺普通的 PC上順暢地玩游戲是不太可能的。 清晰性 ? 清晰意味者所有的工作成果易讀、易理解，可以提高團隊開發(fā)效率，降低維護代價。 Page 10 2. 軟件質(zhì)量屬性和質(zhì)量要素 安全性 ? 這里安全性是指信息安全，英文是 Security而不是 Safety。 ? 在軟件開發(fā)過程中， “ 變化 ” 是司空見慣的事情，如需求、設(shè)計的變化，算法的改進，程序的變化等等。從商業(yè)角度考慮，如果某個軟件將不斷地推出新版本，那么可擴展性很重要。 – 中國聯(lián)通和中國移動的手機互聯(lián)互通問題。這些事故的確不是危言聳聽，給人們敲響了質(zhì)量的警鐘。 在發(fā)射航天器之前 ， 只要發(fā)現(xiàn)任何異常 ， 就會立即取消發(fā)射指令 ， 直到異常被消除為止。 ? 企業(yè)必須權(quán)衡質(zhì)量 、 效率和成本 ， 產(chǎn)品質(zhì)量太低了或者太高了 ， 都不利于企業(yè)獲取利潤 。假設(shè)企業(yè)已經(jīng)制定了軟件過程規(guī)范，如果質(zhì)量保證人員發(fā)現(xiàn)某些項目的“工作過程以及工作成果”不符合既定的規(guī)范，那么馬上可以斷定產(chǎn)品存在缺陷。 我們的過程執(zhí)行得很好 ， 但是我覺得并沒有在很大程度上改善產(chǎn)品的質(zhì)量 。 我們幾乎每一個配置項都要經(jīng)過評審 ， 但是大部分評審都只能發(fā)現(xiàn)一些無關(guān)痛癢的問題 。 我有一些很好的想法卻無處發(fā)揮 ， 所以我很迷茫 ， 很矛盾地考慮去留問題 。 ? 聲援 。 – 我所認識的多數(shù)質(zhì)量人員要么改行了（如當老師），要么讀工程碩士， MBA等，以圖將來發(fā)展事業(yè)。 在企業(yè)中 ， 責任和權(quán)利是成正比的 。 我更喜愛晚上八九點鐘的太陽， 因為他將奏出黎明的交響。 ? 中國郎中看病的故事 在中國古代 ， 有一家三兄弟全是郎中 。 ? 即使一個人嚴守養(yǎng)生之道 ， 身體狀況良好 ， 但總是會意外地得病的 ， 得了病就要去看醫(yī)生 。典型現(xiàn)象是：在軟件交付之前，沒有及時消除缺陷。 ? 誰對軟件質(zhì)量負最大的責任 ？ 誰的權(quán)利越大 ， 他所負的質(zhì)量責任就越大 。 ? 質(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ì)量 。 Page 26 8. 全面軟件質(zhì)量管理：技術(shù)評審 正式技術(shù)評審的流程 ? 技術(shù)評審報告的模板見 word文檔 Page 27 9. 全面軟件質(zhì)量管理：軟件測試 觀點 ? 技術(shù)評審和軟件測試的目的都是為了消除軟件的缺陷，兩者的主要區(qū)別是： – 前者無需運行軟件，評審人員和作者把工作成果擺放在桌面上討論； – 而后者一定要運行軟件來查找缺陷。 Page 28 10. 全面軟件質(zhì)量管理：過程檢查 觀點 ? CMM和 ISO9001所述的軟件質(zhì)量保證 ， 實質(zhì)就是過程檢查 ， 即檢查軟件項目的 “ 工作過程和工作成果 ” 是否符合既定的規(guī)范 。 – 不少機構(gòu)的質(zhì)量人員并沒有真正理解過程檢查的意義，老是對照規(guī)范，查找錯別字、標點符號、排版格式等問題，迷失了方向，這樣只有疲勞沒有功勞，而且讓開發(fā)人員很厭煩。 缺陷跟蹤工具就是幫助項目成員記錄和跟蹤缺陷用的 ， 一般都有數(shù)據(jù)庫支持 ，可以在局域網(wǎng)內(nèi)運行 。 由于缺陷跟蹤工具僅僅是一種輔助性的工具 ， 我們沒有必要太在乎該軟件的功能 ， 只要用起來方便就行 。 Page 29 10. 全面軟件質(zhì)量管理：過程檢查 流程 ? 過程檢查計劃的要點是確定主要檢查項和檢查時間 （ 或頻度 ） 。 為了避免人們誤以為 “ 質(zhì)量保證 ” 能夠 “ 保證質(zhì)量 ” ， 我提議用 “ 過程檢查 ” 取代質(zhì)量保證這個術(shù)語 。 – 相比而言，軟件測試的工作量通常比技術(shù)評審的大，發(fā)現(xiàn)的缺陷也更多。 技術(shù)評審方法已經(jīng)被業(yè)界廣泛采用并收到了很好的效果 ， 它被普遍認為是軟件開發(fā)的最佳實踐之一 。 ? 質(zhì)量人員的主要職責： ? （ 1） 負責制定質(zhì)量計劃 （ 很重要但是工作量比較少 ） ； ? （ 2） 負責過程檢查 （ 類似于 CMM中的質(zhì)量保證 ） ， 約占個人工作量的 20%； ? （ 3） 參與技術(shù)評審 ， 約占個人工作量的 30%； ? （ 4） 參與軟件測試 ， 約占個人工作量的 30%； ? （ 5） 參與軟件過程改進 （ 面向整個機構(gòu) ） ， 約占個人工作量的 20%； * 上述工作量的比例僅供參考 ， 在實際應用時必須根據(jù)項目的特征而定 ?？尚Φ氖?，當軟件系統(tǒng)在用戶那里出故障了，那些現(xiàn)場補救成功的人倒成了英雄，好心用戶甚至還寄來感謝信。 – 同理，在開發(fā)軟件的時候，即使人們的技術(shù)水平很高，并且嚴格遵守規(guī)范，但是人非機器，總是會犯錯誤的，因此無法完全避免軟件中的缺陷。 我二哥通常在人們剛剛生病的