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