軟件質(zhì)量管理

1、第9章 軟件質(zhì)量管理29.1 軟件的質(zhì)量屬性和質(zhì)量要素29.2 商業(yè)目標決定質(zhì)量目標39.3 質(zhì)量保證能夠保證質(zhì)量嗎49.4 質(zhì)量人員的狀況69.4.1 郁悶的質(zhì)量人員69.4.2 路在何方79.4.3 贊美詩89.5 全面軟件質(zhì)量管理99.5.1 模型99.5.2 質(zhì)量人員的職責109.5.3 制定質(zhì)量計劃119.5.4 技術(shù)評審139.5.5 軟件測試169.5.6 過程檢查169.5.7 缺陷跟蹤工具179.6 小結(jié)19第9章 軟件質(zhì)量管理軟件質(zhì)量管理是充滿爭論的話題。被人們奉為軟件質(zhì)量管理圣經(jīng)的CMM和ISO9001似乎并不奏效，現(xiàn)實和理想之間的差距太大。本章樹立一個重要的理念：商業(yè)目

2、標決定質(zhì)量目標。提高軟件質(zhì)量的最終目的是為了贏利，而不是創(chuàng)造完美無缺的產(chǎn)品。因此對于普通商業(yè)軟件而言，并不是“質(zhì)量越高越好”，而是恰好讓廣大用戶滿意，并且將提高質(zhì)量所付出的代價控制在預算之內(nèi)。經(jīng)典軟件工程教科書以及CMM和ISO9001總是拋開商業(yè)目標談質(zhì)量管理，本末倒置，紙上談兵，誤導了大量讀者，所以質(zhì)量管理才變得那么艱辛。本章給出了一套實用主義的“全面軟件質(zhì)量管理”方法。質(zhì)量人員在全面軟件質(zhì)量管理中發(fā)揮重要作用，本章探討了質(zhì)量人員的工作狀況，給他們一些聲援，并提出了改善工作狀況的建議。9.1 軟件的質(zhì)量屬性和質(zhì)量要素在講述軟件質(zhì)量管理方法之前，我們首先要搞清楚什么是軟件質(zhì)量。詞典對質(zhì)量的定

3、義是： 典型的或本質(zhì)的特征； 事物固有的或區(qū)別于其他事物的特征或本質(zhì)； 優(yōu)良或出色的程度。CMM對質(zhì)量的定義是： 一個系統(tǒng)、組件或過程符合特定需求的程度； 一個系統(tǒng)、組件或過程符合客戶或用戶的要求或期望的程度。上述定義很抽象，人們看了準會一臉迷惘。就讓我們用“人的健康”來類比解釋軟件質(zhì)量吧。古時候人們以為長得結(jié)實、飯量大就是健康，這顯然是不科學的。現(xiàn)代人總是通過考察多方面的生理因素來判斷是否健康，如測量身高、體重、心跳、血壓、血液、體溫等。如果上述因素都合格，那么表明這人是健康的。如果某個因素不合格，則表明此人在某個方面不健康，醫(yī)生會對癥下藥。通過類比，我們這樣理解軟件質(zhì)量： 軟件質(zhì)量是許多質(zhì)

4、量屬性的綜合體現(xiàn)，各種質(zhì)量屬性反映了軟件質(zhì)量的方方面面。人們通過改善軟件的各種質(zhì)量屬性，從而提高軟件的整體質(zhì)量（否則無從下手）。軟件的質(zhì)量屬性很多，如正確性、精確性，健壯性、可靠性、容錯性、性能、易用性、安全性、可擴展性、可復用性、兼容性、可移植性、可測試性、可維護性、靈活性等。表9-1是常見質(zhì)量屬性的描述，先讓讀者對軟件質(zhì)量屬性有個初步的了解。質(zhì)量屬性描述正確性正確性是指軟件按照需求正確執(zhí)行任務的能力?！罢_性”的語義涵蓋了“精確性”。正確性無疑是第一重要的軟件質(zhì)量屬性。健壯性健壯性是指在異常情況下，軟件能夠正常運行的能力。正確性與健壯性的區(qū)別是：前者描述軟件在需求范圍之內(nèi)的行為，而后者描述

5、軟件在需求范圍之外的行為。健壯性有兩層含義：一是容錯能力，二是恢復能力?？煽啃钥煽啃允且粋€與時間相關(guān)的屬性，指的是在一定環(huán)境下，在一定的時間段內(nèi)，程序不出現(xiàn)故障的概率，因此是一個統(tǒng)計量，通常用平均無故障時間來衡量。軟件可靠性問題通常是由于設計中沒有料到的異常和測試中沒有暴露的代碼缺陷引起的。性能性能通常是指軟件的“時間空間”效率，而不僅是指軟件的運行速度。人們總希望軟件的運行速度高些，并且占用資源少些。易用性易用性是指用戶使用軟件的容易程度。軟件的易用性要讓用戶來評價。清晰性清晰意味著工作成果易讀、易理解，開發(fā)人員只有在自己思路清晰的時候才可能寫出讓別人易讀、易理解的程序和文檔。安全性安全性是

6、指防止系統(tǒng)被非法入侵的能力，既屬于技術(shù)問題又屬于管理問題。一般地，如果黑客為非法入侵花費的代價（考慮時間、費用、風險等因素）高于得到的好處，那么這樣的系統(tǒng)就可以認為是安全的。可擴展性可擴展性反映了軟件適應“變化”的能力。在軟件開發(fā)過程中，“變化”是司空見慣的事情，如需求、設計的變化，算法的改進、程序的變化等。可擴展性是系統(tǒng)設計階段重點考慮的質(zhì)量屬性。兼容性兼容性是指兩個或兩個以上的軟件相互交換信息的能力。兼容性的商業(yè)規(guī)則是：弱者設法與強者兼容，否則無容身之地；強者應當避免被兼容，否則市場將被瓜分?？梢浦残攒浖目梢浦残灾傅氖擒浖唤?jīng)修改或稍加修改就可以運行于不同軟硬件環(huán)境（CPU、OS和編譯器

7、）的能力，主要體現(xiàn)為代碼的可移植性。表9-1 常見質(zhì)量屬性的描述什么是軟件質(zhì)量要素？它是指：（1）從技術(shù)角度講，對軟件整體質(zhì)量影響最大的那些質(zhì)量屬性才是質(zhì)量要素；（2）從商業(yè)角度講，客戶最關(guān)心的、能成為賣點的質(zhì)量屬性才是質(zhì)量要素。對于一個特定的軟件而言，我們首先判斷什么是質(zhì)量要素，才能給出提高質(zhì)量的具體措施，而不是一股腦地想把所有的質(zhì)量屬性都做好，否則不僅做不好，還可能得不償失。如果某些質(zhì)量屬性并不能產(chǎn)生顯著的經(jīng)濟效益，我們可以忽略它們，把精力用在對經(jīng)濟效益貢獻最大的質(zhì)量要素上。簡而言之，只有質(zhì)量要素才值得開發(fā)人員下功夫去改善。9.2 商業(yè)目標決定質(zhì)量目標大凡軟件工程教科書為了強調(diào)質(zhì)量的重要性

8、，總是要舉一些歷史上發(fā)生過的重大軟件質(zhì)量事故，例如航天飛機爆炸、核電站失事、愛國者導彈發(fā)生故障等等。這些事故的確不是危言聳聽，給人們敲響了質(zhì)量的警鐘。學術(shù)界總是喜歡宣揚質(zhì)量至上的理念，而忽視企業(yè)的商業(yè)利益，將質(zhì)量目標凌駕于商業(yè)目標之上。我不能評判這種現(xiàn)象是好還是壞，但是的確誤導了大量讀者。許多軟件人員都有“質(zhì)量越高越好”的觀念，這是被教科書灌輸?shù)模皇撬约侯I悟出來的。質(zhì)量的最高境界是什么？是盡善盡美，即“零缺陷”。我曾在著作高質(zhì)量程序設計指南C+/C語言中大肆宣揚了高質(zhì)量程序設計的理念，力求使C+程序達到“零缺陷”的質(zhì)量目標。盡管此書得到了許多程序員的贊同，但是我經(jīng)過反思之后改變了質(zhì)量觀念

9、，我要著重指出的是：重視軟件質(zhì)量是應該的，但是“質(zhì)量越高越好”并不是普適的真理。只有極少數(shù)軟件應該追求“零缺陷”，對絕大多數(shù)軟件而言，商業(yè)目標決定了質(zhì)量目標，而不該把質(zhì)量目標凌駕于商業(yè)目標之上。航空航天等系統(tǒng)對質(zhì)量要求極高，任何缺陷都有可能導致機毀人亡，所以人們不惜一切代價去消除缺陷。在發(fā)射航天器之前，只要發(fā)現(xiàn)任何異常，就會立即取消發(fā)射指令，直到異常被消除為止。前蘇聯(lián)做得最過分，許多重大武器系統(tǒng)的負責人都簽了生死狀，系統(tǒng)研制成功則獲得英雄勛章，失敗則被槍斃。在這種壓力下沒有人敢對質(zhì)量有一絲松懈。上述嚴格系統(tǒng)畢竟是少數(shù)，絕大多數(shù)普通軟件的缺陷并不會造成機毀人亡這樣的重大損失，否則沒有人敢從事軟件

10、開發(fā)了。在日常工作中，我們接觸過的軟件幾乎都是有缺陷的，即便是軟件業(yè)老大Microsoft，它的軟件產(chǎn)品也經(jīng)常出錯甚至導致死機，人們罵幾句后還會照樣使用有缺陷的軟件。企業(yè)的根本目標是為了獲取盡可能多的利潤，而不是生產(chǎn)完美無缺的產(chǎn)品。如果企業(yè)銷售出去的軟件的質(zhì)量比較差，輕則挨罵，重則被退貨甚至被索賠，因此為了提高用戶對產(chǎn)品的滿意度，企業(yè)必須提高產(chǎn)品的質(zhì)量。但是企業(yè)不可能為了追求完美的質(zhì)量而不惜一切代價，當企業(yè)為提高質(zhì)量所付出的代價超過銷售收益時，這個產(chǎn)品已經(jīng)沒有商業(yè)價值了，還不如不開發(fā)。企業(yè)必須權(quán)衡質(zhì)量、效率和成本，產(chǎn)品質(zhì)量太低了或者太高了，都不利于企業(yè)獲取利潤。企業(yè)理想的質(zhì)量目標不是“零缺陷”

11、，而是恰好讓廣大用戶滿意，并且將提高質(zhì)量所付出的代價控制在預算之內(nèi)。9.3 質(zhì)量保證能夠保證質(zhì)量嗎質(zhì)量保證（Quality Assurance, QA）是CMM和ISO9001最為推崇的改善軟件質(zhì)量的方法?；谖矣H身實踐和調(diào)查研究，我敢冒天下之大不諱說一句：質(zhì)量保證并不能保證質(zhì)量，它是個美麗的謊言。CMM對軟件質(zhì)量保證是這樣描述的：軟件質(zhì)量保證的目的是為管理者提供有關(guān)軟件過程和產(chǎn)品的適當?shù)目梢曅?。它包括評審和審核軟件產(chǎn)品及其活動，以驗證其是否遵守既定的規(guī)程和標準，并向有關(guān)負責人匯報評審和審核的結(jié)果。簡而言之，質(zhì)量保證活動就是檢查軟件項目的“工作過程和工作成果”是否符合既定的規(guī)范。如此簡單的活動

12、為什么被冠以“質(zhì)量保證”這等份量的術(shù)語呢？沒有歷史典故，經(jīng)我考究，猜想是源于一個天真的假設：過程質(zhì)量與產(chǎn)品質(zhì)量存在某種程度的因果關(guān)系，通?！昂玫倪^程”產(chǎn)生“好的產(chǎn)品”，而“差的過程”將產(chǎn)生“差的產(chǎn)品”。假設企業(yè)已經(jīng)制定了軟件過程規(guī)范，如果質(zhì)量保證人員發(fā)現(xiàn)某些項目的“工作過程以及工作成果”不符合既定的規(guī)范，那么馬上可以斷定產(chǎn)品存在缺陷。反之，如果質(zhì)量保證人員沒有發(fā)現(xiàn)不符合既定規(guī)范的東西，那么也可以斷定產(chǎn)品是合格的?；谏鲜黾僭O，質(zhì)量保證人員即使不是技術(shù)專家，他也能夠客觀地檢查和監(jiān)控產(chǎn)品的質(zhì)量。這是質(zhì)量保證方法吸引人的一面。但是符合既定規(guī)范的東西并不意味著質(zhì)量一定合格，僅靠規(guī)范無法識別出產(chǎn)品中可能

13、存在的大量缺陷。例如，即使程序員們都按照統(tǒng)一的編程規(guī)范來編寫程序，但是編程新手的代碼可能錯誤百出，而高手的代碼則無可挑剔，可是質(zhì)量保證這種方法根本無法識別新手和高手的差距。質(zhì)量保證的技術(shù)含量太低了，只能檢查出膚淺的缺陷，不能對付有技術(shù)難度的缺陷。所以單獨的“質(zhì)量保證”其實并不能“保證質(zhì)量”。有個軟件公司過了CMM3級，其質(zhì)量保證人員給我發(fā)了一個email： 我很迷茫，很想找一個人聊聊，希望你能給我點主意，化解我心中的謎團。昨天我們公司拿到了CMM3的證書，但是我一點都高興不起來。公司宣稱，我們的軟件質(zhì)量大大提高了，但是我卻沒有信心。我們的過程執(zhí)行得很好，但是我覺得并沒有在很大程度上改善產(chǎn)品的質(zhì)

14、量。今天還有一個項目經(jīng)理跟我訴苦：前一階段大家都忙于執(zhí)行過程，但是他的產(chǎn)品質(zhì)量令人很不滿意，尤其是測試做的很不到位。我是這個項目的SQA，所以我很理解他，但是我?guī)筒簧纤拿ΑＲ驗樗麄兊倪^程執(zhí)行得很好，這個項目可是通過CMM3級正式評估了的。當然，執(zhí)行CMM有不少好處，比如文檔全面完整了，項目管理的可視性提高了。但是對于我們公司而言，它并沒有在根本上提高我們公司的軟件能力。比如概要設計，開發(fā)人員根本就不知道用來干嗎的，怎么能指望他們寫出高質(zhì)量的概要設計說明書出來。而在做技術(shù)評審的時候，他們很少能找出邏輯性的錯誤，只能發(fā)現(xiàn)一些諸如錯別字之類的小錯誤。我們幾乎每一個配置項都要經(jīng)過評審，但是大部分評審

15、都只能發(fā)現(xiàn)一些無關(guān)痛癢的問題。公司已經(jīng)通過CMM3級了，我認為過程執(zhí)行得很好了，可是軟件質(zhì)量仍然比較差。這是怎么回事啊，你覺得原因在哪里？這個email很有代表性，它反映了一個共性問題：公司按照CMM3級的要求執(zhí)行，而且質(zhì)量人員也認為執(zhí)行過程符合既定的規(guī)范，但是軟件產(chǎn)品的質(zhì)量仍然低下。所以我說“質(zhì)量保證并不能保證質(zhì)量”，這句話一點都不過分。質(zhì)量保證對于保證質(zhì)量而言只是必要的手段，而不是充分的手段。質(zhì)量保證這個術(shù)語名不副實，含義模糊，我強烈建議將“質(zhì)量保證”改名為“過程檢查”，免得誤導國內(nèi)企業(yè)。那么怎么才能保證軟件的質(zhì)量呢？請閱讀本章第5節(jié)“全面軟件質(zhì)量管理”。9.4 質(zhì)量人員的狀況9.4.1

16、郁悶的質(zhì)量人員由于工作關(guān)系，我和不少軟件機構(gòu)的質(zhì)量人員打過交道。我覺得有必要反映一下質(zhì)量人員的狀況，給他們一些聲援。接上個email，那位質(zhì)量人員繼續(xù)向我訴說：我現(xiàn)在覺得很郁悶，CMM評估前還有目標，評估完了冷靜下來卻覺得效果很差，很沒勁。項目經(jīng)理向我訴苦，他們過程執(zhí)行的很好，但是對產(chǎn)品質(zhì)量很不滿意，我卻無能為力，我這個QA還有什么用處??！所以我現(xiàn)在干活沒有動力，因為不能產(chǎn)生效益，做再多的工作也覺得是白干。而且我現(xiàn)在手頭有5個項目要跟蹤，還不包括一些整理培訓記錄的雜活，我覺得自己連工人也不如。我有一些很好的想法卻無處發(fā)揮，所以我很迷茫，很矛盾地考慮去留問題。類似的email我大概收到十來個。在

17、漢語字典里找不到“郁悶”這個詞，它是現(xiàn)代人發(fā)明的。郁悶的滋味各色各樣，只有正在郁悶的人感受最真切。我發(fā)現(xiàn)在軟件職業(yè)里，質(zhì)量人員是最郁悶的一族。郁悶的共同特征有：（1）在執(zhí)行質(zhì)量保證活動時，經(jīng)常受別人的氣，真是吃力不討好。（2）如果項目取得成功，主要功勞都被項目主管霸占了，領導們至多會給質(zhì)量人員一些口頭上的感謝。領導們嘴上重視產(chǎn)品的質(zhì)量，但是內(nèi)心并不重視質(zhì)量人員。（3）質(zhì)量人員沒有實質(zhì)性的權(quán)力，沒有成就感，但是卻對質(zhì)量負有最多的責任。（4）待遇一般，看不到升遷的機會，沒有盼頭，要么成為打雜的，要么另尋出路。在企業(yè)里，職位是有高低之分的，但是人人都是平等的。郁悶的滋味是很不好受的，為啥老是讓質(zhì)量人

18、員郁悶呢，這顯然很不公平。我曾經(jīng)做過傷害質(zhì)量人員的事情，現(xiàn)在良心發(fā)現(xiàn)，在這里道個歉，并聲援他們。兩年前，我在一個軟件事業(yè)部負責推廣軟件工程和CMM。公司領導比較重視，給我6個全職人員，有充足的資金，聲勢浩大，那時我比較自負，很少采用協(xié)商的方式解決糾紛。公司有專門的質(zhì)量部門，定期到各事業(yè)部檢查質(zhì)量。由于我們事業(yè)部采用的是CMM，而質(zhì)量部門采用的是ISO9000標準，我不懂他的，他不懂我的，所以產(chǎn)生了糾紛。事業(yè)部的各級領導都有銷售壓力，用他們的話說是：沒有時間陪質(zhì)量部門的人“玩”，大家都有“對付”而不是“配合”質(zhì)量部門的心態(tài)。有一次質(zhì)量部門要檢查某個重點項目的文檔，偏偏這個項目是保密的，一方要檢查

19、一方要保密，雙方弄僵了。在事業(yè)部內(nèi)部開會的時候，這個重點項目的負責人大發(fā)脾氣說：我最煩那些人，看么看不懂，還老是來檢查，別說項目是保密的，就是不保密的我也不給看。大家火得很熱烈，我就火上加油給質(zhì)量部門發(fā)了email，大致意思是“你們搞ISO9000的人不懂軟件工程，不懂CMM，不懂得軟件開發(fā)卻老是來檢查軟件項目，對本事業(yè)部只有干擾而沒有幫助”，email言詞激烈。我把email發(fā)給一位和我打交道比較多的質(zhì)量部人員，并抄送給本事業(yè)部所有人員，給本部門大大地出了一口氣。過了幾天，我收到質(zhì)量部同事的email，足足有兩頁紙。有幾句話我記憶很深刻：收到你的email時我十分震驚。依你的身份，當著事業(yè)部

20、百余名員工的面，把工作上的怨氣發(fā)在我這個無辜的人的頭上，我實在難以接受。提高產(chǎn)品質(zhì)量是我們的工作職責，我們并不想和任何人爭吵。觀念的差異可以通過交流、協(xié)商的方式來解決，我不強求你接受任何東西，但真心希望能對你有所觸動，并歡迎你和我或我的同事繼續(xù)探討、交流。我非常后悔，因為我傷害了一個十分友善而且敬業(yè)的質(zhì)量部同事。而更糟糕的是，我這個例子只不過是冰山一角而已。我所認識的公司內(nèi)外的質(zhì)量人員都是性格溫和、細致耐心的人，他們的優(yōu)點在于人格而不是技術(shù)。平心而論，他們比技術(shù)出色但是情商不高的技術(shù)人員更值得交朋友。質(zhì)量檢查是他們的工作職責，誰也不會有意干擾項目，所以任何人都不應該向他們發(fā)火。9.4.2 路在

21、何方我的一位同事在干了5年的質(zhì)量保證工作后，終于厭倦了，到某大學軟件學院當老師去了，目前看上去比較滿意。有一位生物專業(yè)畢業(yè)的、做了多年ISO9000的同事和我談心，她也說很想當大學老師，當然不教質(zhì)量管理的課程，而是希望重拾她的生物專業(yè)。那位平白無故受我怨氣的質(zhì)量部同事正在讀MBA，學得很好，我想她必定有更好的追求。上節(jié)email的作者一邊上班一邊讀工程碩士，她的工作任務有一些變動：我已經(jīng)轉(zhuǎn)做測試了，主要原因有以下幾個：1、我們的過程質(zhì)量雖然很好，但是在提高產(chǎn)品質(zhì)量方面沒有達到期望的效果；2、測試是保證產(chǎn)品質(zhì)量的一種重要手段，我要接觸一下，從而對產(chǎn)品的質(zhì)量有更好的理解；3、這段時間項目不多，我比

22、較空閑，而且只做SQA的工作，有點枯燥；4、我們公司的測試力量比較薄弱，我希望能幫忙做點什么；5、長期以來，沒有深入項目的感覺，我希望自己能夠親身去執(zhí)行我們的過程，看看能不能找出點問題；同時，我也沒有放棄SQA的工作，以后在做測試的同時，我會至少兼做一個項目的SQA。我想這樣是一個相輔相成的過程。我希望自己能對提高軟件產(chǎn)品質(zhì)量做點貢獻。你看了email就知道她是一位積極上進的好員工，她靠自己的悟性在摸索解決問題的方法。她碰到的問題我看得很清楚，絕非個別現(xiàn)象。問題的根源是：她公司的領導不懂得真正有效的質(zhì)量管理，使她無法發(fā)揮全職質(zhì)量人員的價值。軟件行業(yè)里的人嘴上都說質(zhì)量很重要，可是大多數(shù)企業(yè)并沒有

23、給質(zhì)量人員提供良好的職業(yè)發(fā)展空間。質(zhì)量人員通常僅給企業(yè)起到心里安慰的作用。這樣下去，有能耐的質(zhì)量人員會跑光的。在大多數(shù)的軟件企業(yè)里，男性處于支配地位，女性職位相對比較低。而質(zhì)量人員通常是女性，很多男性主管從未真正地把質(zhì)量人員當成企業(yè)的寶貴人才看待，這種偏見是非常有害的。任何素質(zhì)合格的員工都是寶貴的人才，很多默默無聞的人才其實是被不懂得管理的領導給荒廢了。質(zhì)量人員之所以沒有發(fā)揮預期的效果，不是性別緣故，主要過失在于領導者。企業(yè)領導們要好好反省，你自己不懂質(zhì)量管理，不是瞎指揮嗎？我的建議如下：（1）無論是企業(yè)領導還是質(zhì)量人員，都要好好學習全面軟件質(zhì)量管理方法，結(jié)合企業(yè)的特點給出真正有效的質(zhì)量管理方

24、案。（2）只有當企業(yè)領導采用了正確的質(zhì)量管理方案，用了合格的質(zhì)量人員，才可能看得到比較明顯的質(zhì)量改善，才能形成良性循環(huán)。（3）如果想讓質(zhì)量人員負起比較重的責任，那么就要給她相應的權(quán)力。在企業(yè)中，責任和權(quán)利是成正比的。如果質(zhì)量人員的地位無足輕重，那么必然導致質(zhì)量管理無足輕重。（4）給質(zhì)量人員一個適宜的升遷機會和薪資待遇，讓她能夠快樂地工作，而不是成天無奈地檢查質(zhì)量。9.4.3 贊美詩在我寫這本書的時候，中國正遭受非典型肺炎（SARS）的肆虐。人們在危難之際想起了醫(yī)護人員的好處，因此涌現(xiàn)了許多對醫(yī)護人員的贊美詩。我碰巧在網(wǎng)上搜索到一位軟件詩人獻給質(zhì)量人員的贊美詩“晚上八九點鐘的太陽”，我看了不禁喜

25、悅和感動。我認為沒有必要等到軟件質(zhì)量災難降臨的時候才想起質(zhì)量人員，于是摘錄這首詩公布于此。詩中的“狼人”和“銀彈”是軟件工程的典故，寓意深刻。衷心感謝這位不知姓名的浪漫軟件詩人。晚上八九點鐘的太陽獻給軟件測試和質(zhì)保人員我更喜愛晚上八九點鐘的太陽，雖然人們都已把他遺忘，但他還是艱難地懸掛在天上。我更喜愛晚上八九點鐘的太陽，因為他將奏出黎明的交響。沒有他又怎會呼喚出一片明亮？我更喜愛晚上八九點鐘的太陽，因為他會化成早上的朝陽。沒有他又怎會有什么希望？我更喜愛晚上八九點鐘的太陽，因為他是上帝的臂膀。沒有他，又怎會創(chuàng)造萬物的光芒。狼人望月嚎叫，它知道月亮映出的太陽之光，終將化為銀彈，射入它的胸膛。我更

26、喜愛晚上八九點種的太陽。9.5 全面軟件質(zhì)量管理9.5.1 模型如果一個人渾身上下都沒有毛病，那么他就很健康；反之如果渾身是病，那么就不健康。所以毛病是健康的死對頭。同理，質(zhì)量的死對頭是缺陷，缺陷是混在產(chǎn)品中的人們不喜歡、不想要的東西，它對產(chǎn)品沒有好處只有壞處。人們常說的Bug就是缺陷的形象比喻。顯然，缺陷越多質(zhì)量越低，缺陷越少質(zhì)量越高，提高軟件質(zhì)量的基本手段是消除軟件缺陷。讓我們看看中國郎中治病的故事，受點啟發(fā)。在中國古代，有一家三兄弟全是郎中。其中有一人是名醫(yī)，人們問他：“你們兄弟三人誰的醫(yī)術(shù)最高？”他回答說：“我常用猛藥給病危者醫(yī)治，偶爾有些病危者被我救活，于是我的醫(yī)術(shù)遠近聞名并成了名醫(yī)

27、。我二哥通常在人們剛剛生病的時候馬上就治愈他們，臨近村莊的人說他是好郎中。我大哥不外出治病，他深知人們生病的原因，所以能夠預防家里人生病，他的醫(yī)術(shù)只有我們家里才知道。”上述故事里，郎中三兄弟是三種治病方式的代言人。相似地，提高軟件質(zhì)量也有三種方式。老大治病的方式最高明，如果人們能夠預防生病的話，那么沒病就用不著看醫(yī)生了。提高軟件質(zhì)量最好的辦法是：在開發(fā)過程中有效地防止工作成果產(chǎn)生缺陷，將高質(zhì)量內(nèi)建于開發(fā)過程之中。主要措施是“不斷地提高技術(shù)水平，不斷地提高規(guī)范化水平”，其實就是練內(nèi)功，通稱為“軟件過程改進”。即使一個人嚴守養(yǎng)生之道，身體狀況良好，但總是會意外地得病的，得了病就要去看醫(yī)生。老二治病

28、的方式就是醫(yī)院的模式，病人越早看病，就越早治好，治病的代價就越低。同理，在開發(fā)軟件的時候，即使人們的技術(shù)水平很高，并且嚴格遵守規(guī)范，但是人非機器，總是會犯錯誤的，因此無法完全避免軟件中的缺陷。那么怎么辦呢？當工作成果剛剛產(chǎn)生時馬上進行質(zhì)量檢查，及時找出并消除工作成果中的缺陷。這種方式效果比較好，人們一般都能學會。最常用的方法是技術(shù)評審、軟件測試和過程檢查，已經(jīng)被企業(yè)廣泛采用并取得了成效。老三治病的方式代價最高，只能是不得已而為之?？稍诂F(xiàn)實之中，大多數(shù)軟件企業(yè)采用老三的方式來對付質(zhì)量問題。典型現(xiàn)象是：在軟件交付之前，沒有及時消除缺陷。當軟件交付給用戶后，用著用著就出錯了，趕緊請開發(fā)者來補救。可笑

29、的是，當軟件系統(tǒng)在用戶那里出故障了，那些現(xiàn)場補救成功的人倒成了英雄，好心用戶甚至還寄來感謝信。借鑒老大、老二治病的方法，我們提煉出全面軟件質(zhì)量管理的模型，如圖9-1所示。項目中的所有人員幾乎都參與了質(zhì)量活動，只是介入的程度不同而已，本章后面幾節(jié)將逐一介紹這些質(zhì)量活動。軟件過程改進：提高軟件技術(shù)水平和規(guī)范化水平軟件項目X軟件測試過程檢查技術(shù)評審缺陷跟蹤制定質(zhì)量計劃圖9-1 全面軟件質(zhì)量管理的模型9.5.2 質(zhì)量人員的職責誰對軟件質(zhì)量負責？是全員負責。任何與軟件開發(fā)、管理工作相關(guān)的人員都對質(zhì)量產(chǎn)生影響，都要對質(zhì)量負責。所以人們不要把質(zhì)量問題全部推出質(zhì)量人員或測試人員。誰對軟件質(zhì)量負最大的責任？誰的

30、權(quán)利越大，他所負的質(zhì)量責任就越大。質(zhì)量人員是成天與質(zhì)量打交道的人，但他個人并不對產(chǎn)品質(zhì)量產(chǎn)生最大的影響，所以也不負最大的責任。前面分析過了，如果質(zhì)量人員僅僅從事質(zhì)量保證活動的話，那么他對軟件開發(fā)和管理的介入就非常膚淺，對提高質(zhì)量缺乏實質(zhì)性貢獻，最終導致他很“郁悶”。在圖9-1的模型中，質(zhì)量人員的主要職責是：² 負責制定質(zhì)量計劃（很重要但是工作量比較少）；² 負責過程檢查（類似于CMM中的質(zhì)量保證），約占個人工作量的20%；² 參與技術(shù)評審，約占個人工作量的30%；² 參與軟件測試，約占個人工作量的30%；² 參與軟件過程改進（面向整個機構(gòu)），約

31、占個人工作量的20%；上述工作量的比例僅供參考，在實際應用時必須根據(jù)項目的特征而定。技術(shù)評審與軟件測試關(guān)注的是產(chǎn)品質(zhì)量而不是過程質(zhì)量，兩者的技術(shù)強度比過程檢查要高得多，更加容易發(fā)現(xiàn)缺陷。技術(shù)評審和軟件測試能彌補過程檢查的不足，我們不能將過程檢查、技術(shù)評審和軟件測試的觀念混為一談，但是也不能把三者孤立起來。質(zhì)量人員除了過程檢查之外，還要參加（并監(jiān)督）重要的技術(shù)評審和測試工作，這樣做才富有成效。軟件過程改進是面向整個機構(gòu)的，而不僅僅是針對某個項目的。由于質(zhì)量人員的日常工作主要是過程檢查、技術(shù)評審、軟件測試，成天與質(zhì)量問題打交道，所以他能發(fā)現(xiàn)整個機構(gòu)的共性質(zhì)量問題，因此質(zhì)量人員參與軟件過程改進是很有

32、意義的。軟件過程改進一般由SEPG（Software Engineering Process Group）負責。我曾經(jīng)和不少CMM咨詢師和SEPG的負責人交流過，多數(shù)人認為SEPG是“立法機構(gòu)”，質(zhì)量小組是“執(zhí)法機構(gòu)”，兩者應該徹底分開。我認為這種設想很不適合中國中小型軟件機構(gòu)（100人以下），企業(yè)又不是國家政法機構(gòu)，哪有那么多的人和錢去搞理想主義??！圖9-1的模型完全出于實用主義，所以不受ISO9000和CMM的約束。9.5.3 制定質(zhì)量計劃質(zhì)量計劃就是為了實現(xiàn)質(zhì)量目標的計劃。而質(zhì)量目標則是由商業(yè)目標決定的。開發(fā)軟件產(chǎn)品的最終目的是為了賺錢，所以人們?yōu)樘岣哕浖|(zhì)量所付出的代價是有上限的，項目

33、負責人當然希望代價越低越好。質(zhì)量計劃就是全面質(zhì)量管理的行動綱領。誰制定質(zhì)量計劃？由項目核心成員和質(zhì)量人員共同協(xié)商制定，主要由質(zhì)量人員起草，由項目經(jīng)理審批即可。表9-2為軟件質(zhì)量計劃的參考模板。XXX軟件質(zhì)量計劃1. 質(zhì)量要素分析 提示：從商業(yè)利益和技術(shù)角度判斷哪些質(zhì)量屬性是本軟件的質(zhì)量要素，說明為什么，這樣相關(guān)人員可以把精力集中在改善質(zhì)量要素上。質(zhì)量要素優(yōu)先級解釋2. 質(zhì)量目標提示：給出各個質(zhì)量要素的恰當目標，既要使客戶感到滿意，又要使開發(fā)方承受得起。質(zhì)量要素目標3. 人員與職責提示：項目中的許多人員將參與各種質(zhì)量活動，說明他們的職責。人員質(zhì)量活動、職責描述4. 過程檢查計劃過程域、主要檢查項

34、時間或頻度負責人5. 技術(shù)評審計劃待評審的工作成果評審時間負責人6. 軟件測試計劃測試活動名稱時間負責人7. 缺陷跟蹤工具提示：說明本項目采用何種缺陷跟蹤工具，以及簡要的使用約定。8. 審批意見提示：項目經(jīng)理審批本計劃表9-2 軟件質(zhì)量計劃的模板9.5.4 技術(shù)評審技術(shù)評審（Technical Review, TR）的目的是盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時消除缺陷，從而有效地提高產(chǎn)品的質(zhì)量。技術(shù)評審最初是由IBM公司為了提高軟件質(zhì)量和提高程序員生產(chǎn)率而倡導的。技術(shù)評審方法已經(jīng)被業(yè)界廣泛采用并收到了很好的效果，它被普遍認為是軟件開發(fā)的最佳實踐之一。技術(shù)評審的主要好處有：²

35、 通過消除工作成果的缺陷而提高產(chǎn)品的質(zhì)量；² 技術(shù)評審可以在任何開發(fā)階段執(zhí)行，不必等到軟件可以運行之際，越早消除缺陷就越能降低開發(fā)成本；² 開發(fā)人員能夠及時地得到同行專家的幫助和指導，無疑會加深對工作成果的理解，更好地預防缺陷，一定程度上提高了開發(fā)生產(chǎn)率。技術(shù)評審有兩種基本類型：² 正式技術(shù)評審（FTR）。FTR比較嚴格，需要舉行評審會議，參加評審會議的人員比較多。² 非正式技術(shù)評審（ITR）。ITR的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，評審人員比較少。理論上講，為了確保產(chǎn)品的質(zhì)量，產(chǎn)品的所有工作成果都應當接受技術(shù)評審。現(xiàn)實中，為了節(jié)約時

36、間，允許人們有選擇地對工作成果進行技術(shù)評審。技術(shù)評審方式也視工作成果的重要性和復雜性而定。將重要性、復雜性各分“高、中、低”3個等級。重要性復雜性組合與技術(shù)評審方式的對應關(guān)系如表9-3所示。在制定質(zhì)量計劃的時候，應該確定技術(shù)評審計劃，見表9-2。重要性復雜性組合技術(shù)評審方式（FTR, ITR）高高FTR高中FTR高低FTR 或者ITR均可中中FTR 或者ITR均可中低ITR低低ITR表9-3 重要性復雜性組合與技術(shù)評審方式的對應關(guān)系本節(jié)重點介紹正式技術(shù)評審的流程，如圖9-2所示。2.5會議結(jié)束決議2.4討論缺陷解決方案2.3識別缺陷和答辯2.2作者介紹工作成果2.1主持人宣講Step1. 準備

37、評審Step3. 跟蹤與審核Step2. 舉行評審會議圖9-2 正式技術(shù)評審的流程第一步 準備評審² 評審主持人首先確定評審會議的時間、地點、設備和參加會議的人員名單（包括評審員、記錄員、作者、旁聽者等），并告知所有相關(guān)人員（例如email）。² 評審主持人把工作成果及相關(guān)材料、技術(shù)評審規(guī)程、檢查表等發(fā)給評審員。² 評審員閱讀（了解）工作成果及相關(guān)材料。第二步 舉行評審會議² Step2.1 主持人宣講本次評審會議的議程、重點、原則、時間限制等。² Step2.2 作者扼要地介紹工作成果。² Step2.3 評審員根據(jù)“檢查表”認真查

38、找工作成果的缺陷。作者回答評審員的問題，雙方要對每個缺陷達成共識（避免誤解）。² Step2.4 作者和評審員共同討論缺陷的解決方案。對于當場難以解決的問題，由主持人決定“是否有必要繼續(xù)討論”或者“另定時間再討論”。² Step2.5 評審小組給出評審結(jié)論和意見，主持人簽字后本次會議結(jié)束。評審結(jié)論有三種：（1） 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。（2） 工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。（3） 工作成果基本合格，需要作少量的修改，之后通過審核即可，轉(zhuǎn)向第三步。 第三步 跟蹤與審核² 作者修正工作成果，消除已發(fā)現(xiàn)的缺

39、陷。評審主持人（或者指定審查員）跟蹤每個缺陷的狀態(tài)。直到工作成果合格為止。技術(shù)評審報告的模板如表9-4所示。XXX技術(shù)評審報告1. 基本信息提示：由評審主持人或記錄員填寫成果介紹名稱，版本，作者，時間等等評審時間評審地點評審會議名單角色、職務人員A評審主持人人員B2. 問答記錄提示：由評審主持人或記錄員填寫，主要記錄評審過程中的疑問、答復、爭論、處理意見記錄A記錄B3. 評審結(jié)論與意見提示：由評審主持人填寫評審結(jié)論 工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。 工作成果基本合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。意見

40、建議簽字主持人簽字4. 缺陷跟蹤與審核提示：如果使用了缺陷跟蹤軟件，那么無需手工填寫此表，用軟件生成缺陷報表就行。缺陷描述缺陷解決方案、結(jié)果表9-4 技術(shù)評審報告的模板技術(shù)評審是個團體活動，一般地，機構(gòu)沒有專職地技術(shù)評審人員，當需要技術(shù)評審的時候臨時組織人員就可以了。質(zhì)量人員一定要參與技術(shù)評審活動（大約占其工作量的30左右），建議讓質(zhì)量人員主持那些重要的技術(shù)評審會議，免得開發(fā)人員忘記了技術(shù)評審。9.5.5 軟件測試技術(shù)評審和軟件測試的目的都是為了消除軟件的缺陷，兩者的主要區(qū)別是：前者無需運行軟件，評審人員和作者把工作成果擺放在桌面上討論；而后者一定要運行軟件來查找缺陷。技術(shù)評審在軟件測試之前執(zhí)

41、行，尤其是在需求開發(fā)和系統(tǒng)設計階段。相比而言，軟件測試的工作量通常比技術(shù)評審的大，發(fā)現(xiàn)的缺陷也更多。本書第7章已經(jīng)深入介紹了軟件測試的方法與技術(shù)，本節(jié)不再累贅。這里要著重強調(diào)的是，軟件測試、技術(shù)評審、過程檢查、缺陷跟蹤都是全面質(zhì)量管理不可缺少的組成部分。在制定質(zhì)量計劃的時候，已經(jīng)確定了本項目的主要測試活動、時間和負責人，之后再考慮軟件測試的詳細計劃和測試用例。如果機構(gòu)沒有專職的軟件測試人員的話，那么開發(fā)人員可以兼職做測試工作。當項目開發(fā)到后期，過程檢查和技術(shù)評審都已經(jīng)沒有多少意義了，開發(fā)小組急需有人幫助他們測試軟件，如果質(zhì)量人員參與軟件測試，對開發(fā)小組而言簡直就是“雪中送炭”。本章強調(diào)，質(zhì)量人

42、員一定要參與軟件測試（大約占其工作量的30左右），只有這樣他才能深入地了解軟件的質(zhì)量問題，而且給予開發(fā)小組強有力地幫助。9.5.6 過程檢查CMM和ISO9001所述的軟件質(zhì)量保證，實質(zhì)就是過程檢查，即檢查軟件項目的“工作過程和工作成果”是否符合既定的規(guī)范。“過程檢查”這個詞雖然沒有質(zhì)量保證那么動聽，但是其含義直接明了，不會讓人誤解。為了避免人們誤以為“質(zhì)量保證”能夠“保證質(zhì)量”，我提議用“過程檢查”取代質(zhì)量保證這個術(shù)語。雖然本章批判了“質(zhì)量保證”的浮夸，但是并沒有全盤否定質(zhì)量保證的好處。過程檢查對提高軟件質(zhì)量是有幫助的，只是它的好處沒有象質(zhì)量保證鼓吹的那么好而已。例如，機構(gòu)制定了配置管理規(guī)范，要求每個項目都進行版本控制，但是在項目的實際開發(fā)過程中，許多開發(fā)人員并沒有對其工作成果進行版本控制。萬一版本發(fā)生混亂，必定對項目產(chǎn)生負面影響。如果質(zhì)量人員在過程檢查時發(fā)現(xiàn)了這個問題，那么他就有責任要求開發(fā)人員執(zhí)行版本控制，如果開發(fā)人員不接受這個好意，那么質(zhì)量人員就要向上級領導反映這個問題，直至消除隱患為止。再例如，機構(gòu)制定了重要工作成果的文檔模板（例如需求規(guī)格說明書、設計報告等），要求開發(fā)人員寫的文檔盡可能符合模板。如果質(zhì)量人員發(fā)現(xiàn)開發(fā)人員寫的文檔與機構(gòu)的模板差異非常大，那么就要搞清楚究竟是模板不合適？還是開發(fā)人員偷工減料大大簡化了模板？符合規(guī)范的工作成果不見得就是高質(zhì)量的，但是