【正文】 品質(zhì)量的理論和方法，有的從技術(shù)角度出發(fā)，例如：面向?qū)ο蠹夹g(shù)的產(chǎn)生和推廣，第四代語言的誕生等等；有的從自動化工具入手，例如： CASE 工具、過程控制軟件、自動化管理平臺等；有的從過程模型角度出發(fā)，例如：迭代模型、螺旋模型、 RUP 、 IPD 、凈室軟件工程等；也有從管理角度出發(fā)的，例如：團(tuán)隊管理、績效管理、 PSP 、 TSP 等；也有從測試角度出發(fā)的，例如：加強全流程的測試等；一些相應(yīng)的規(guī)范和標(biāo)準(zhǔn)也孕育而生，例如： ISO9000 系列、 CMM 、 QMS 等。然而每一種技術(shù)都不是絕對的，軟件質(zhì)量的提高應(yīng)該是一個綜合的因素，需要從每個方面進(jìn)行改進(jìn)，同時還需要兼顧成本和進(jìn)度。 6．1 什么是質(zhì)量 作為軟件產(chǎn)品的銷售人員，市場人員或維護(hù)人員經(jīng)常會受到客戶這樣那樣的指責(zé)或抱怨，客戶說：你們產(chǎn)品的質(zhì)量太差，不穩(wěn)定等等。那么什么是質(zhì)量呢？我們該如何來衡量質(zhì)量呢？ 質(zhì)量具有三個維度： ? 符合目標(biāo)。目標(biāo)是客戶所定義的，符合目標(biāo)即判斷我們是不是在做需要做的事情。 ? 符合需求。即產(chǎn)品是不是在做讓它做的事情。 ? 符合實際需求。實際的需求包括用戶明確說明的和隱含的需求。 ISO 關(guān)于質(zhì)量的定義表示如下： “ 一個實體（產(chǎn)品或服務(wù)）的所有特性，基于這些特性可以滿足明顯的或隱含的需要。 ” 注意，在這個定義中包含明顯的需求和隱含的需求。而往往我們會忽略隱含的需求。因此在控制一個產(chǎn)品的質(zhì)量的過程中必須關(guān)注這些隱含的需求，并給予應(yīng)有的驗證。 另一方面因為我們的產(chǎn)品是為客戶提供服務(wù)的，因此凡是不滿足客戶需求的，我們都認(rèn)為是一個失效（ failure ）。所以我們的產(chǎn)品必須始終圍繞著客戶的需求進(jìn)行開發(fā)和驗證。 這里我們談到客戶，其實在一個軟件的需求收集過程中需要關(guān)注客戶和用戶。而我們經(jīng)常會忽略客戶與用戶之間的區(qū)別。那么誰是客戶？誰是用戶呢？簡單的來說，客戶是真正能夠決定是否購買你軟件的人，而用戶是實際使用軟件的人。了解了這個區(qū)別，對于你在分析需求的重要性的時候就可以進(jìn)行參考。同時在產(chǎn)品質(zhì)量驗證的時候也可以做出不同的權(quán)衡。另一方面我們在考慮我們用戶需求的時候，往往只考慮了實際使用軟件的人員，而忽略了其它一些人員對軟件的要求或?qū)浖斐傻臐撛诟偁?，這包括維護(hù)人員的要求、系統(tǒng)管理人員的要求、軟件上下游人員的要求、先前版本的情況、市場上競爭對手的軟件情況等。 每個人提到質(zhì)量的時候，經(jīng)常會遇到下列矛盾，在這些矛盾中隱含著對質(zhì)量的承諾【 5 】： ? 質(zhì)量需要一個承諾，尤其是高層管理者的承諾。但為了得到質(zhì)量，高層管理者必須和其雇用的員工進(jìn)行緊密合作； ? 許多人相信沒有缺陷的產(chǎn)品和服務(wù)是不可能的。但是控制在一定級別的缺陷數(shù)是正常并可接受的； ? 質(zhì)量經(jīng)常是和成本緊密聯(lián)系在一起，一個高質(zhì)量的產(chǎn)品同時也意味著高投入。這是設(shè)計的質(zhì)量和一致性質(zhì)量的一個矛盾； ? 一個高的質(zhì)量要求需求規(guī)格說明書足夠詳細(xì)，以便產(chǎn)品可以根據(jù)這些規(guī)格說明書進(jìn)行定量的分析。然而許多組織沒有能力或者不愿意產(chǎn)生如此詳細(xì)程度的規(guī)格說明書； ? 技術(shù)人員經(jīng)常相信規(guī)范和標(biāo)準(zhǔn)會束縛他們的創(chuàng)造力，因此就不遵照標(biāo)準(zhǔn)做事。然而如果要得到高質(zhì)量的產(chǎn)品，就必須遵循良好定義的標(biāo)準(zhǔn)和過程。 6．2 流程對質(zhì)量的貢獻(xiàn) 好了，既然已經(jīng)了解了什么是質(zhì)量，那么怎么才能改進(jìn)軟件產(chǎn)品的質(zhì)量呢？從一個企業(yè)的長遠(yuǎn)發(fā)展來看，首先應(yīng)當(dāng)從流程抓起，規(guī)范軟件產(chǎn)品的開發(fā)過程。這是一個軟件企業(yè)從小作坊的生產(chǎn)方式向集成化、規(guī)范化的大公司邁進(jìn)的必經(jīng)之路，也是從根本上解決質(zhì)量問題，提高工作效率的一個關(guān)鍵手段。 軟件產(chǎn)品的開發(fā)同其它產(chǎn)品（如汽車）的生產(chǎn)有著共同特性，即需要按一定的過程來進(jìn)行生產(chǎn)。在工業(yè)界，流水線生產(chǎn)方式被證明是一種高效且能夠比較穩(wěn)定地保證產(chǎn)品質(zhì)量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個目標(biāo)共同努力，這樣可以防止人員工作間的內(nèi)耗，極大的提高工作效率。并且由于其過程來源于成功的實例，因此其最終的產(chǎn)品質(zhì)量能夠滿足過程所設(shè)定的范圍要求。軟件工程在軟件的發(fā)展過程中吸取了這個經(jīng)驗并把它應(yīng)用到了軟件開發(fā)中，這就形成了軟件工程過程，簡單的說就是開發(fā)流程。 無論做什么事情，都有一個循序漸進(jìn)的過程，從計劃到策略再到實現(xiàn)。軟件流程就是按照這種思維來定義開發(fā)過程，它根據(jù)不同的產(chǎn)品特點和以往的成功經(jīng)驗，定義了從需求到最終產(chǎn)品交付的一整套流程。流程告訴我們該怎么一步一步去實現(xiàn)產(chǎn)品，可能會有那些風(fēng)險，如何去避免風(fēng)險等等。由于流程來源于成功的經(jīng)驗，因此，按照流程進(jìn)行開發(fā)可以使得我們少走彎路，并有效的提高產(chǎn)品質(zhì)量，提高用戶的滿意度。 目前流行的流程方法有很多種，不同的過程模型適合于不同類型的項目。瀑布模型是應(yīng)用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。然而，對于那些容易理解但很復(fù)雜的項目，采用瀑布模型會是比較適合的，因為你可以按部就班的去處理復(fù)雜的問題。在質(zhì)量要求高于成本和進(jìn)度要求的時候，該模型表現(xiàn)的尤其突出。 螺旋模型是也是一個經(jīng)典模型，它關(guān)注于發(fā)現(xiàn)和降低項目的風(fēng)險【 8 】。螺旋型項目從小的規(guī)模開始，然后探測風(fēng)險，制定風(fēng)險控制計劃，接著確定下一步項目是否還要繼續(xù)，然后進(jìn)行下一個螺旋的反復(fù)。該模型的最大優(yōu)點就是隨著成本的增加，風(fēng)險程度隨之降低。然而螺旋模型的缺點是比較復(fù)雜，且需要管理人員有責(zé)任心，專注以及有管理方面經(jīng)驗。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發(fā)過程模型，它是一個面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程【 9 】。它描述了一系列相關(guān)的軟件工程流程，它們具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。 RUP 為在開發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計的時間安排和預(yù)算內(nèi)開發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。 RUP 具有兩個軸，一個是時間軸，這是動態(tài)的。另一個是工作流軸，這是靜態(tài)的。在時間軸上， RUP 劃分了四個階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個階段都使用了迭代的概念。在工作流軸上， RUP 設(shè)計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計工作流、實現(xiàn)工作流、測試工作流和發(fā)布工作流。核心支撐工作流包括：環(huán)境工作流、項目管理工作流和配置與變更管理工作流。具體可以參考圖 1 。 RUP 匯集現(xiàn)代軟件開發(fā)中多方面的最佳經(jīng)驗，并為適應(yīng)各種項目及組織的需要提供了靈活的形式。作為一個商業(yè)模型，它具有非常詳細(xì)的過程指導(dǎo)和模板。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。圖1 RUP 工作流程示意圖 IPD （ Integrated Product Development ）流程是由 IBM 提出來的一套集成產(chǎn)品開發(fā)流程，非常適合于復(fù)雜的大型開發(fā)項目，尤其涉及到軟硬件結(jié)合的項目。 IPD 從整個產(chǎn)品角度出發(fā)，流程綜合考慮了從系統(tǒng)工程、研發(fā)（硬件、軟件、結(jié)構(gòu)工業(yè)設(shè)計、測試、資料開發(fā)等）、制造、財務(wù)到市場、采購、技術(shù)支援等所有流程。是一個端到端的流程。在 IPD 流程中總共劃分了六個階段（概念階段、計劃階段、開發(fā)階段、驗證階段、發(fā)布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術(shù)評審點，具體可以參考圖 2 。 IPD 流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復(fù)雜的流程來把一個龐大而又復(fù)雜的系統(tǒng)進(jìn)行分解并降低風(fēng)險。一定程度上，該模型是通過流程成本來提高整個產(chǎn)品的質(zhì)量并獲得市場的占有。由于該流程沒有定義如何進(jìn)行流程回退的機制，因此對于需求經(jīng)常變動的項目該流程就顯得不大適合了。并且對于一些小的項目，也不是非常適合使用該流程。圖2 IPD 流程示意圖 6．3 流程與技術(shù) 流程和成功不是等價的。沒有流程就成功是不可能得到保證，但有了流程并不意味著肯定能夠成功。這恐怕是很多迷信于流程的人所不能接受的。但這的確是個事實。記得有個做了將近 30 多年的需求分析專家說過：即使是一個已經(jīng)達(dá)到 CMM4 級的公司，也完全有可能做不好需求分析。為什么？技術(shù)，技術(shù)是成功的另外一個必要條件。就好比現(xiàn)在你要從上海到北京去，流程給你指出了最短的路徑，技術(shù)提供給你最快的交通工具。兩者結(jié)合就是完美。 對于軟件開發(fā)來說，要保證軟件的質(zhì)量，需要掌握多方面的技術(shù)，包括分析技術(shù)、設(shè)計技術(shù)、編碼技術(shù)和測試技術(shù)等等。在國內(nèi)有一個普遍的非正?，F(xiàn)象，就是大家覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個比喻會打擊很多程序員的自尊心，但這的確是一個事實。我們?nèi)鄙傧到y(tǒng)級的工程師，在分析和設(shè)計方面的工作做得很不扎實。 需求是一個項目的靈魂。模棱兩可的需求帶來不可避免的后果便是返工 —— 重做一些你認(rèn)為已做好的事情。返工會耗費開發(fā)總費用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的錯誤所導(dǎo)致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發(fā)出產(chǎn)品，在同樣的時間內(nèi)開發(fā)更多、更好的產(chǎn)品，甚至能偶爾回家休息休息。在《軟件需求》一書中關(guān)于如何進(jìn)行需求分析給出了比較詳細(xì)的介紹【 7 】， RUP 中關(guān)于需求的指導(dǎo)也是很實用的。 設(shè)計是最能體現(xiàn)一個工程師能力和水平的環(huán)節(jié)。一個好的設(shè)計基本上決定了產(chǎn)品的最終質(zhì)量。設(shè)計是把需求轉(zhuǎn)換成系統(tǒng)的一個關(guān)鍵步驟，它需要從自然語言描述的需求中尋找出設(shè)計的基礎(chǔ)單元，構(gòu)建出整個系統(tǒng)的構(gòu)架。在 RUP 中關(guān)于系統(tǒng)構(gòu)架師和設(shè)計師的定位是相當(dāng)高的。關(guān)于設(shè)計方面的技能涉及面是很廣的，包括傳統(tǒng)的結(jié)構(gòu)化設(shè)計到面向?qū)ο笤O(shè)計。設(shè)計人員需要掌握一定的建模技術(shù)。 UML 是國際上比較流行的一種建模語言【 11 】。在嵌入式方面， SDL 也是一種非常好的選擇。《設(shè)計模式》是在設(shè)計思想方面總結(jié)的非常出色的一本書【 6 】，作為一名設(shè)計人員（尤其是面向?qū)ο笤O(shè)計人員）必須要好好研究一下。但是對這些模式的應(yīng)用應(yīng)當(dāng)講究一種自然的應(yīng)用，千萬不要因為模式而去設(shè)計模式，否則會適得其反。 現(xiàn)在的程序員熱中于掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規(guī)范化。不規(guī)范的語言應(yīng)用給程序的可理解性、可維護(hù)性以及可測試性帶來了大的傷害，進(jìn)而損害了產(chǎn)品的質(zhì)量。某公司曾對中國程序員和印度程序員做過一個測驗，這個測驗要求參加者對一組數(shù)進(jìn)行排序。測試結(jié)果發(fā)現(xiàn)，印度程序員設(shè)計的程序使用的算法并不是最優(yōu)，但卻是最不容易出錯的，并且?guī)讉€程序員寫出來的代碼如出一轍。而幾個中國程序員寫出的代碼，有的非常漂亮，很精練，效率很高；有的卻很冗雜，還有錯誤。如果大家是在做研究性的項目或純粹興趣性的項目，那么充分發(fā)揮自己的編程天才也無可厚非。然而，對于一個軟件公司，產(chǎn)品最終是要交給用戶的，需要遵循的是一個軟件產(chǎn)品的開發(fā)工程。因此這類軟件的開發(fā)需要遵循一定的編程規(guī)范，畢竟開發(fā)的軟件不是自己用，還需要和別人的集成，還需要給以后版本重用和維護(hù)。 測試的技術(shù)將在第五節(jié)進(jìn)行闡述。總之流程很關(guān)鍵，技術(shù)也很重要，我的觀點是：魚和熊掌，兩者都不能放。 6．4 全面質(zhì)量管理 自從 Deming 的全面質(zhì)量管理（ TQM ）原則在日本工業(yè)界獲得了巨大成功之后，這個原則迅速被傳播到了世界各個地方，同樣，全面質(zhì)量管理原則也被應(yīng)用到了軟件開發(fā)當(dāng)中。如前面提到的，軟件開發(fā)也是一個工程性的工作，因此必須提高整個工程的質(zhì)量。產(chǎn)業(yè)界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明設(shè)計活動引入的錯誤占軟件過程中出現(xiàn)所有錯誤（和最終的缺陷）數(shù)量的 50 ％到 65 ％。根據(jù) IBM 的研究表明，假定在分析階段發(fā)現(xiàn)的錯誤其改正成本為 1 個單位的話，那么在測試之前（設(shè)計編碼階段）發(fā)現(xiàn)一個錯誤的修改成本約為 個貨幣單位，在測試時（集成測試，系統(tǒng)測試和驗收測試）發(fā)現(xiàn)一個錯誤的修改成本約為 15 個貨幣單位，而在發(fā)布之后（已經(jīng)交到用戶手上）發(fā)現(xiàn)一個錯誤的修改成本約為 60 到 100 個貨幣單位。同樣該比例也適用用于發(fā)現(xiàn)一個錯誤需要的時間。我們可以看下面兩條曲線圖： 圖3 缺陷代價曲線 為了提高產(chǎn)品質(zhì)量，縮短產(chǎn)品開發(fā)進(jìn)度，節(jié)約產(chǎn)品開發(fā)成本，必須盡早的進(jìn)行產(chǎn)品質(zhì)量控制。全面質(zhì)量控制要求在過程的每個階段每個步驟上都要進(jìn)行嚴(yán)格的驗證和確認(rèn)活動。 什么是驗證？ 驗證 就是要用數(shù)據(jù)證明我們是不是在正確的制造產(chǎn)品。注意這里強調(diào)的是過程的正確行【 12 】。 什么是確認(rèn)？ 確認(rèn) 就是要用數(shù)據(jù)證明我們是不是制造了正確的產(chǎn)品。注意這里強調(diào)的是結(jié)果的正確性。 IEEE 給出的驗證和確認(rèn)過程可以用下圖來表示。驗證和確認(rèn)是一個廣泛的概念，感興趣的讀者可以參考 IEEE Std 10121998 。 圖4 驗證和確認(rèn)模型 6．5 關(guān)注測試 軟件測試是軟件質(zhì)量控制中的關(guān)鍵活動。業(yè)界的統(tǒng)計數(shù)據(jù)表明，測試的成本大約占軟件開發(fā)總成本的 50 ％左右。 軟件測試的目的是要發(fā)現(xiàn)軟件中的錯誤。一個好的測試是發(fā)現(xiàn)至今沒有被發(fā)現(xiàn)的錯誤。傳統(tǒng)的軟件測試專注于動態(tài)測試范疇，如：單元測試，集成測試和系統(tǒng)測試。而測試工程的發(fā)展已經(jīng)進(jìn)入到了全流程的測試，包括開發(fā)過程前期的靜態(tài)測試。 一般我們可以把測試分為白盒測試和黑盒測試。 白盒測試 ：顧名思義，白盒測試應(yīng)當(dāng)是透明的。的確，該類測試是根據(jù)程序代碼的內(nèi)部邏輯結(jié)構(gòu)來設(shè)計測試用例進(jìn)行測試。那么什么是測試用例？ 一個 測試用例 就是一個文檔，描述輸入、動作、或者時間和一個期望的結(jié)果，其目的是確定應(yīng)用程序的某個特性是否正常的工作。 黑盒測試 ：看了白盒測試的解釋，我想你很快就能猜出黑盒測試是不考慮程序內(nèi)部結(jié)構(gòu)情況的。事實上也是這樣。黑盒測試是根據(jù)規(guī)格說明書進(jìn)行的測試。 規(guī)格說明書 記錄了用戶的需求。比如用戶希望在編輯器中增加查找功能，那么我們把該需求寫入規(guī)格說明書，根據(jù)該項要求，直接調(diào)用應(yīng)用程序的該項功能進(jìn)行測試，而不管其內(nèi)部是用什么算法實現(xiàn)的。