如何提高軟件質(zhì)量第一頁，共55頁。主題什么是軟件質(zhì)量？軟件質(zhì)量的過去和將來！我們遇到了什么？或者即將遇到什么？怎么辦？參考資料第二頁，共55頁。什么是質(zhì)量？質(zhì)量具有三個維度：?

符合目標(biāo)。目標(biāo)是客戶所定義的，符合目標(biāo)即判斷我們是不是在做需要做的事情。?

符合需求。即產(chǎn)品是不是在做讓它做的事情。?

符合實際需求。實際的需求包括用戶明確說明的和隱含的需求。ISO關(guān)于質(zhì)量的定義表示如下：“一個實體（產(chǎn)品或服務(wù)）的所有特性，基于這些特性可以滿足明顯的或隱含的需要。”第三頁，共55頁。什么是軟件質(zhì)量？外部用戶要求:正確,高效,健壯,易用和可靠內(nèi)部維護人員要求:可維護(代碼易讀,易讀,易Debug,注釋清晰,容易擴展)內(nèi)部測試人員要求:可測試,易用,易理解企業(yè)產(chǎn)品化要求:可擴展,可移植,可配置,靈活,重用性高,模塊和組件化

第四頁，共55頁。代碼大全怎么說因此《代碼大全》將軟件質(zhì)量特征分為內(nèi)部質(zhì)量特征和外部質(zhì)量特征:

外部質(zhì)量特征包括:

+正確性。整個系統(tǒng)受說明、設(shè)計和實現(xiàn)的錯誤影響程度。

+可用性。用戶學(xué)會和使用系統(tǒng)的難易程度。

+效率。對系統(tǒng)資源的最小利用，包括存儲和執(zhí)行時間。

+可靠性。在一定條件下執(zhí)行特定功能的能力。

+完整性。防止非法或不適當(dāng)?shù)卦L問。完整性思想包括：限制非法用戶訪問，同時確保證數(shù)據(jù)恰當(dāng)訪問；并行數(shù)據(jù)表進行并行修改；數(shù)據(jù)段僅含有有效數(shù)據(jù)等等。

+適應(yīng)性。系統(tǒng)在應(yīng)用或其它環(huán)境下不作修改就能使用的能力。

+精確性。系統(tǒng)不受錯誤影響的程度，尤其是數(shù)據(jù)輸出方面。精確性和正確性是不同的。精確性是對系統(tǒng)完成其工作性能良好的衡量，而不是它設(shè)計得是否正確。

+堅固性。系統(tǒng)對無效輸入或壓力環(huán)境中能繼續(xù)執(zhí)行其功能的能力。

第五頁，共55頁。代碼大全怎么說內(nèi)部質(zhì)量特征包括:

+可維護性。修改一個軟件系統(tǒng)，提高其性能或修正其錯誤的能力。

+靈活性。修改系統(tǒng)使其能適應(yīng)于不同的用途或環(huán)境的能力，而不必對系統(tǒng)進行特定的設(shè)計。

+可移植性。能修改所設(shè)計的某一系統(tǒng)使其能在其它環(huán)境下運行的能力。

+可重用性。能將系統(tǒng)的一部分用于其它系統(tǒng)的難易程度。

+可讀性。能讀懂或理解系統(tǒng)源代碼的能力，尤其是在細節(jié)說明這一級上。

+可測試性。對整個系統(tǒng)進行單元或系統(tǒng)測試以證實其滿足所有需求性能的測試難易程度。

+可理解性。能從整個系統(tǒng)水平或細節(jié)說明這一級上理解整個系統(tǒng)的難易程度。可理解性要比可讀性從更一般的水平上討論系統(tǒng)的緊密性。

第六頁，共55頁。我們把影響軟件質(zhì)量的因素分成三組，分別反映用戶在使用軟件產(chǎn)品時的三種不同傾向或觀點。這三種傾向是：產(chǎn)品運行、產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。信息系統(tǒng)作為一個產(chǎn)品，也可以參照這三種傾向來定義。

第七頁，共55頁。我們需要注意的幾個數(shù)據(jù)1、在項目發(fā)布后發(fā)現(xiàn)和修復(fù)Bug的成本是需求和設(shè)計階段所需的一百倍！2、80%可避免的重復(fù)勞動源自于20%的缺陷，其中兩大主要來源包括草率的需求定制和象征性的案例設(shè)計和開發(fā)。3、大約80%的缺陷來自20%的模塊，而約半數(shù)的模塊是幾乎沒有缺陷。4、90%的軟件的停工期最多來自于10%的缺陷。第八頁，共55頁。總結(jié)一下上面四條原則說明了兩個問題，一是錯誤越早發(fā)現(xiàn)成本越低，而且大部分的錯誤都是在軟件開發(fā)的前面階段引入的。二是大部分的錯誤都集中在少數(shù)的模塊。第九頁，共55頁。缺陷代價曲線第十頁，共55頁。軟件質(zhì)量的過去20世紀(jì)60年代中期，美國的首次金星探測計劃，因為在FORTRAN語言程序的DO語句中漏掉一個逗號，慘遭失敗。1996年，歐洲航天局首次發(fā)射阿麗亞娜5號火箭失敗，其直接原因是火箭控制系統(tǒng)的軟件故障，導(dǎo)致直接經(jīng)濟損失5億美元，還使耗資80億美元的開發(fā)計劃延遲了三年。1986年3月到1987年1月，由加拿大原子能有限公司生產(chǎn)的Therac25放射治療機造成兩人死亡、數(shù)人受傷。第十一頁，共55頁。軟件質(zhì)量的過去1992年，法國倫教由于救護派遺系統(tǒng)全部崩潰，導(dǎo)致多名病人因為搶救不及時而失去生命。1991年海灣戰(zhàn)爭期間，美國愛國者導(dǎo)彈由于軟件計時系統(tǒng)累計誤差造成攔截失敗，造成人員無辜傷亡。1990年美國電話系統(tǒng)中新投入使用的軟件發(fā)生失效，導(dǎo)致主千線遠程網(wǎng)大規(guī)模崩潰，給運營商造成了重大的經(jīng)濟損失。1991年，由于一系列局域電話網(wǎng)因軟件錯誤而中斷，造成了數(shù)以千計依靠電訊公司運營業(yè)務(wù)的公司遭受巨額的資金損失。第十二頁，共55頁。軟硬件產(chǎn)品的不同點特征軟件硬件存在形式虛擬、動態(tài)固化、穩(wěn)定客戶需求不確定性相對清楚度量性非常困難正常生產(chǎn)過程邏輯性強流水線、工序邏輯關(guān)系復(fù)雜清楚接口復(fù)雜多數(shù)簡單、適中維護復(fù)雜、新的需求、可以不斷打補丁多數(shù)簡單、適中、沒有新的需求第十三頁，共55頁。軟硬件開發(fā)過程的比較軟件

硬件54-56%質(zhì)量缺陷來自需求不清楚需求分析《＝》調(diào)研分析質(zhì)量控制的主要階段之一25%質(zhì)量缺陷來自設(shè)計和編程設(shè)計、編程《＝》設(shè)計階段質(zhì)量控制的主要階段之一

測試《＝》設(shè)計審查

發(fā)布《＝》設(shè)計完成

這里不是軟件質(zhì)量管理的主要階段軟件拷貝《＝》制造、檢驗生產(chǎn)的主要過程，質(zhì)量控制的重點不僅支持原有功能，解決以前就存在的問題，而且增加新特性、加強新功能維護《＝》維修支持原有功能，解決運行中出現(xiàn)的問題，一般比較容易預(yù)測第十四頁，共55頁。我們遇到了什么？項目沒有被很好地理解；計劃不周，最終導(dǎo)致進度拖延。沒有充分的文檔資料。人與人的交流比寫程序困難得多。軟件可靠性缺少度量的標(biāo)準(zhǔn)，質(zhì)量無法保證。軟件難以維護、不易升級，問題越改越多。第十五頁，共55頁。如何改進我們的軟件質(zhì)量的思考從一個企業(yè)的長遠發(fā)展來看，首先應(yīng)當(dāng)從流程抓起，規(guī)范軟件產(chǎn)品的開發(fā)過程。這是一個軟件企業(yè)從小作坊的生產(chǎn)方式向集成化、規(guī)范化的大公司邁進的必經(jīng)之路，也是從根本上解決質(zhì)量問題，提高工作效率的一個關(guān)鍵手段。第十六頁，共55頁。瀑布模型編程設(shè)計需求分析測試維護瀑布模型是應(yīng)用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。然而，對于那些容易理解但很復(fù)雜的項目，采用瀑布模型會是比較適合的，因為你可以按部就班的去處理復(fù)雜的問題。在質(zhì)量要求高于成本和進度要求的時候，該模型表現(xiàn)的尤其突出。第十七頁，共55頁。RAD模型（V模型）第十八頁，共55頁。螺旋模型（1）制定計劃：確定軟件目標(biāo)，選定實施方案，弄清項目開發(fā)的限制條件；（2）風(fēng)險分析：分析評估所選方案，考慮如何識別和消除風(fēng)險；（3）實施工程：實施軟件開發(fā)和驗證；（4）客戶評估：評價開發(fā)工作，提出修正建議，制定下一步計劃。螺旋型項目從小的規(guī)模開始，然后探測風(fēng)險，制定風(fēng)險控制計劃，接著確定下一步項目是否還要繼續(xù)，然后進行下一個螺旋的反復(fù)。該模型的最大優(yōu)點就是隨著成本的增加，風(fēng)險程度隨之降低。然而螺旋模型的缺點是比較復(fù)雜，且需要管理人員有責(zé)任心，專注以及有管理方面經(jīng)驗。第十九頁，共55頁。RUP（RationalUnifiedProcess）RUP工作流程示意圖第二十頁，共55頁。IPD（IntegratedProductDevelopment）IPD流程示意圖第二十一頁，共55頁。目前主要的一些軟件開發(fā)過程模型瀑布模型原型模型快速應(yīng)用開發(fā)(RAD)模型螺旋模型噴泉模型增量模型和迭代模型構(gòu)件組裝模型并發(fā)模型第二十二頁，共55頁。流程與技術(shù)流程和成功不是等價的。沒有流程就成功是不可能得到保證，但有了流程并不意味著肯定能夠成功。這恐怕是很多迷信于流程的人所不能接受的。但這的確是個事實。記得有個做了將近30多年的需求分析專家說過：即使是一個已經(jīng)達到CMM4級的公司，也完全有可能做不好需求分析。為什么？技術(shù)，技術(shù)是成功的另外一個必要條件總之流程很關(guān)鍵，技術(shù)也很重要，我的觀點是：魚和熊掌，兩者都不能放。第二十三頁，共55頁。我們的遇到的問題對于軟件開發(fā)來說，要保證軟件的質(zhì)量，需要掌握多方面的技術(shù)，包括分析技術(shù)設(shè)計技術(shù)、編碼技術(shù)測試技術(shù)在國內(nèi)有一個普遍的非正常現(xiàn)象，就是大家覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個比喻會打擊很多程序員的自尊心，但這的確是一個事實。我們?nèi)鄙傧到y(tǒng)級的工程師，在分析和設(shè)計方面的工作做得很不扎實。第二十四頁，共55頁。我們需要做好的地方UML代表軟件建模的發(fā)展趨勢需求分析的能力學(xué)習(xí)好《設(shè)計模式》測試技術(shù)程序員也要有扎實的文檔編寫能力良好的編程習(xí)慣第二十五頁，共55頁。關(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)進入到了全流程的測試，包括開發(fā)過程前期的靜態(tài)測試第二十六頁，共55頁。關(guān)于測試的一些介紹白盒測試

黑盒測試單元測試

集成測試

系統(tǒng)測試

第二十七頁，共55頁。改善軟件質(zhì)量的技術(shù)軟件質(zhì)量目標(biāo)明確定義質(zhì)量保證工作測試策略軟件工程指南非正式技術(shù)復(fù)查（review,walk-through)正式技術(shù)復(fù)查外部審查第二十八頁，共55頁。缺陷檢測率第二十九頁，共55頁。第三十頁，共55頁。國際上流行的質(zhì)量標(biāo)準(zhǔn)（CMM)軟件能力成熟度模型是目前國內(nèi)軟件企業(yè)中非常受歡迎的一個質(zhì)量標(biāo)準(zhǔn)。并且該標(biāo)準(zhǔn)已經(jīng)成為業(yè)界一個事實上的標(biāo)準(zhǔn)。CMM為軟件組織提供了一個指導(dǎo)性的管理框架。在這個框架的指導(dǎo)下：?

軟件組織可以對其軟件開發(fā)、維護過程獲得控制。?

軟件組織可以推進其軟件工程更為科學(xué)、推進軟件過程管理更為卓越。?

CMM通過確定當(dāng)前軟件過程管理的成熟度，通過標(biāo)識軟件的質(zhì)量和過程改進中關(guān)鍵的、要害的問題，可以指導(dǎo)軟件組織選擇正確的軟件過程改進策略。?

CMM將其焦點，聚焦在一系列具體的軟件過程活動上，并以侵略方式（Aggressively）達到這些活動。一個軟件組織就可以穩(wěn)定地、持續(xù)地改進其整個軟件組織過程，使得其軟件過程管理能力取得持續(xù)地、持久地不斷爭長提高。第三十一頁，共55頁。CMM的五個等級在CMM中，把軟件工廠分為五個等級：初始級可重復(fù)級已定義級管理級優(yōu)化級第三十二頁，共55頁。軟件過程是未加定義的隨意過程，項目的執(zhí)行是隨意甚至是混亂的。也許，有些企業(yè)制定了一些軟件工程規(guī)范，但若這些規(guī)范未能覆蓋基本的關(guān)鍵過程要求，且執(zhí)行沒有政策、資源等方面的保證時，那么它仍然被視為初始級。初始級可重復(fù)級人們根據(jù)多年的經(jīng)驗和教訓(xùn)，總結(jié)出軟件開發(fā)的首要問題不是技術(shù)問題而是管理問題。因此，第二級的焦點集中在軟件管理過程上。一個可管理的過程則是一個可重復(fù)的過程，可重復(fù)的過程才能逐漸改進和成熟。可重復(fù)級的管理過程包括了需求管理、項目管理、質(zhì)量管理、配置管理和子合同管理五個方面；其中項目管理過程又分為計劃過程和跟蹤與監(jiān)控過程。通過實施這些過程，從管理角度可以看到一個按計劃執(zhí)行的且階段可控的軟件開發(fā)過程。

已定義級要求制定企業(yè)范圍的工程化標(biāo)準(zhǔn)，并將這些標(biāo)準(zhǔn)集成到企業(yè)軟件開發(fā)標(biāo)準(zhǔn)過程中去。所有開發(fā)的項目需根據(jù)這個標(biāo)準(zhǔn)過程裁剪出與項目適宜的過程，并且按照過程執(zhí)行。過程的裁剪不是隨意的，在使用前必須經(jīng)過企業(yè)有關(guān)人員的批準(zhǔn)。

CMM的等級說明第三十三頁，共55頁。CMM級別與軟件質(zhì)量關(guān)系表格每千行軟件的缺陷數(shù)目軟件過程成熟度等級軟件準(zhǔn)時提交的百分比每人每月生產(chǎn)的程序行數(shù)軟件需要返工的百分比平均軟件失效時間（近似）大于10初始級<=50Z>=452到60分鐘小于10可重復(fù)級901.5Z201-160小時小于1已定義級992.5Z10不確定小于0.1管理級降低開發(fā)時間到1/25Z5不確定小于0.01優(yōu)化級降低開發(fā)時間到1/410Z<=2近似完全可靠第三十四頁，共55頁。改進我們的軟件質(zhì)量吧根據(jù)不同業(yè)務(wù)特點可以選擇瀑布模型，迭代模型等，并在這些模型上進行適當(dāng)?shù)淖兓赃m應(yīng)于短平快的產(chǎn)品開發(fā)特點

實施簡潔的開發(fā)過程體系提高需求分析和設(shè)計方面的技術(shù)，例如：原型法技術(shù)，分析模式，設(shè)計模式，面向?qū)ο笤O(shè)計，UML等；

提高需求分析和設(shè)計方面的技術(shù)第三十五頁，共55頁。改進我們的軟件質(zhì)量吧加強編程規(guī)范工作

進行適當(dāng)?shù)臏y試工作，建議進行單元測試和系統(tǒng)測試

實施配置管理工作，加強版本控制

開展走讀、評審和檢視活動，尤其要加強代碼走讀，建議進行每日交叉走讀活動進行簡單的度量分析獲得質(zhì)量數(shù)據(jù)第三十六頁，共55頁。給軟件開發(fā)人員的一些忠告我的源代碼給貓吃了！？1在所有弱點中，最大的弱點就是害怕暴露弱點2提供各種選擇，不要找蹩腳的理由第三十七頁，共55頁。不要容忍破窗戶軟件的熵定期為你的知識資產(chǎn)投資你的知識資產(chǎn)第三十八頁，共55頁。交流！知道你要說什么了解你聽眾選擇時機，選擇風(fēng)格讓文檔美觀讓聽眾參與做傾聽者回復(fù)他人第三十九頁，共55頁。重復(fù)的危害強加的重復(fù)無意的重復(fù)無耐性的重復(fù)開發(fā)者之間的重復(fù)不要重復(fù)你自己讓復(fù)用變的更容易第四十頁，共55頁。軟件的正交性消除無關(guān)事物之間的影響提示如果顯著的改變某個特定功能背后的需求，有多少模塊會受影響？第四十一頁，共55頁。軟件的正交性讓你的代碼保持解耦避免使用全局變量避免編寫相似的函數(shù)單元測試第四十二頁，共55頁。曳光彈使用曳光彈找到目標(biāo)用戶能夠及早看到能工作的東西開發(fā)者構(gòu)建了一個他們能夠在其中工作的結(jié)構(gòu)你有了一個集成平臺你有了可以演示的東西你將更能夠感覺到工作的進展曳光代碼原型制作第四十三頁，共55頁。估算時長報出估算的單位1-15天天3-8周周8-30周月30+周努力思考一下再回答檢查需求分析風(fēng)險設(shè)計，實現(xiàn)，集成向用戶確認我等會回答你！第四十四頁，共55頁。源代碼控制總是應(yīng)該使用源代碼控制第四十五頁，共55頁。按照合約進行設(shè)計（DBC)前條件后條件類不變項第四十六頁，共55頁。死程序不說謊要崩潰，不要破壞（早