項目質(zhì)量控制的工具和技術(shù)分析3

　　摘要：8．6．4質(zhì)量控制圖和七點運行法則 控制圖(controlchart)是數(shù)據(jù)的圖形表示，表明一個過程隨時間變化的結(jié)果。漢弗萊說，平均起來，程序員每9—10行編碼就會產(chǎn)生一個軟件缺陷，完成的軟件全部測試之后，每千行編碼大約包含5—6個軟件缺陷。

　　8．6．4質(zhì)量控制圖和七點運行法則

　　控制圖(controlchart)是數(shù)據(jù)的圖形表示，表明一個過程隨時間變化的結(jié)果?？刂茍D的主要用途是為了預(yù)防缺陷，而不是檢測或拒絕缺陷。質(zhì)量控制圖可以使你確定一個過程是受控還是失控。當(dāng)一個過程是受控的，過程結(jié)果中的任何變化都是由隨機(jī)事件產(chǎn)生的。受控的過程不需要調(diào)節(jié)。當(dāng)一個過程是失控，過程結(jié)果中的變化是由非隨機(jī)事件產(chǎn)生的。當(dāng)一個過程失控，你需要確認(rèn)這些非隨機(jī)事件的起因，并調(diào)節(jié)過程以糾正或消除這些起因?？刂茍D常常用來監(jiān)控批量制造，但也能用于監(jiān)控變更請求的數(shù)量和頻率、文件中的錯誤、成本和進(jìn)度偏差，以及其他與項目質(zhì)量管理有關(guān)的事項。

　　圖8-3是制造12英寸尺子的過程控制圖示例。假定這是在一條裝配線上由機(jī)器生產(chǎn)的木制尺子。圖表上每一點代表下線尺子的長度測量值?？v軸的尺度從11．90—12．10。這些數(shù)字代表尺子規(guī)格的下限和上限。在這種情況下，這將意味著訂購尺子的顧客明確指定他們買的所有尺子的長必須在11．90—12．10英寸之間或12±0．10英寸。在質(zhì)量控制圖中，下控制界限和上控制界限分別是1，1．91和12．09英寸。這意味著設(shè)計制造過程生產(chǎn)長度在11．91到12．09英寸之間的尺子。

　　注意圖上在12．03英寸、12.06英寸和]2．09英寸等處的虛線。這些虛線分別代表這些點在平均值以上一個、兩個和三個標(biāo)準(zhǔn)差。在11．97英寸、11．94英寸和11．91英寸等處的虛線分別代表這些點在平均值以下一個、兩個和三個標(biāo)準(zhǔn)差?；谇笆?u>+3 的統(tǒng)計學(xué)定義，如果制造過程是受控的，99．73％的下線尺子的測量值在11．91—12．09英寸之間。

　　 尋找并分析過程數(shù)據(jù)的模型是質(zhì)量控制的一個重要部·分?？梢允褂觅|(zhì)量控制圖和七點運行法則來尋找數(shù)據(jù)的模型。七點運行法則(Sevenrunrule)指出，如果質(zhì)量控制圖上連續(xù)的7個數(shù)據(jù)點都在平均值以下、都在平均值以上、或者所有點都呈現(xiàn)出上升或下降的趨勢，那么需要檢查這個過程是否有非隨機(jī)問題。在圖8—3中，違背了七點運行法則的數(shù)據(jù)點標(biāo)注了星號。注意，包含第一點在內(nèi)的一系列點都是上升或下降的情況。在尺子制造過程中，這些數(shù)據(jù)點可能表明一個校準(zhǔn)裝置需要調(diào)整。比如，為制造尺子，切木頭的機(jī)器可能需要調(diào)整，或機(jī)器上的刀片需要更換。

　　8．6．5 測試

　　許多IT專業(yè)人員認(rèn)為測試是IT產(chǎn)品開發(fā)臨近結(jié)束時的階段。一些公司不是在IT項目的適當(dāng)計劃、分析和設(shè)計上下功夫，而只是依靠在一個產(chǎn)品交貨之前的測試來確保一定程度的質(zhì)量。實際上，在系統(tǒng)開發(fā)生命周期的幾乎每個階段都需要測試，而不僅在一個產(chǎn)品被送達(dá)或交付顧客之前。

　　圖8—4顯示了描繪系統(tǒng)開發(fā)生命周期的一個方式。這個例子包括一個軟件開發(fā)項目中17個主要任務(wù)，并顯示了他們彼此間的關(guān)系。例如，每個項目應(yīng)當(dāng)由項目啟動開始，然后做可行性研究，再做項目計劃編制。此圖表明，接下來準(zhǔn)備詳細(xì)系統(tǒng)需求分析和系統(tǒng)架構(gòu)的工作可以同時展開。圖中橢圓形代表實際的測試或任務(wù)，包括測試計劃以確保OA軟件開發(fā)項目的質(zhì)量。

　　圖8—4中的幾個階段包括與測試相關(guān)的具體工作。單元測試(unittest)是對每個單獨部件(經(jīng)常是一個程序)進(jìn)行測試，以確保它盡可能的無缺陷。單元測試是在集成測試之前進(jìn)行的。集成測試(Integrationtesting)是在單元測試和系統(tǒng)測試之間進(jìn)行，用來測試功能性的分組組件，以確保全部系統(tǒng)的各子集模塊協(xié)同運行。系統(tǒng)測試(systemtesting)是將整個系統(tǒng)作為一個整體進(jìn)行測試。它著重于從宏觀上來確保整個系統(tǒng)正常工作。用戶驗收測試(useracceptancetesting)是一個獨立的測試，在系統(tǒng)交付驗收之前由終端用戶執(zhí)行。它重點測試系統(tǒng)對組織業(yè)務(wù)的適應(yīng)性，而非技術(shù)問題。

　　圖8—5是一個甘特圖，顯示適于系統(tǒng)開發(fā)生命周期不同階段的測試工作?！患易稍児驹么俗鳛樵敿?xì)測試管理計劃，不過這里給出的是其簡化形式。為了幫助改進(jìn)軟件開發(fā)項目的質(zhì)量，對于組織來說，遵循一個嚴(yán)謹(jǐn)?shù)臏y試方式是非常重要的。系統(tǒng)開發(fā)者和測試者也必須與項目所有的干系人建立伙伴關(guān)系，以確保系統(tǒng)能夠滿足他們的需要和期望，同時也保證測試被正確地執(zhí)行。正如下節(jié)所描述的，相應(yīng)測試的失敗將產(chǎn)生巨大的成本。

　　但是，根據(jù)卡內(nèi)基·梅隆軟件工程學(xué)會特別會員和著名軟件質(zhì)量專家瓦特·漢弗萊(WatlS．Humphrey)的觀點，測試不能解決所有軟件缺陷問題。漢弗萊認(rèn)為傳統(tǒng)的編碼一測試一安裝的軟件開發(fā)周期是不夠的。當(dāng)編碼變得越來越復(fù)雜時，未得到檢測的缺陷就會增加，這不僅成為測試者的問題，也成為了付費用戶的問題。漢弗萊說，平均起來，程序員每9—10行編碼就會產(chǎn)生一個軟件缺陷，完成的軟件全部測試之后，每千行編碼大約包含5—6個軟件缺陷。雖然有相多不同的定義，但漢弗萊將軟件缺陷(softwaredefect)定義為在軟件交付之前必須更正的問題，

　　由于測試一個復(fù)雜系統(tǒng)的規(guī)模是巨大的，所以，測試并不能完全地防止軟件缺陷。另外，用戶將不斷創(chuàng)造那些開發(fā)者從未考慮過的新方法去使用系統(tǒng)，因此，某些功能特性可能從未被測試，甚至這些功能特性就沒包含在系統(tǒng)需求中。漢弗萊建議人們在進(jìn)入系統(tǒng)測試的時候，重新思考軟件開發(fā)流程，以避免產(chǎn)生潛在的軟件缺陷。這就意味著開發(fā)者在每一個測試階段必須負(fù)責(zé)提供無誤的編碼。漢弗萊提出一個開發(fā)流程，在這個流程里，程序員測量和跟蹤他們所犯的各種錯誤，這樣，他們就能夠應(yīng)用這些資料來改善他們的業(yè)績。漢弗萊也承認(rèn)高層管理必須支持開發(fā)人員，允許他們自主地工作。程序員們需要激勵和鼓勵去做高質(zhì)量的工作，他們對如何做這些工作也需要一些適當(dāng)?shù)目刂啤?/p>>

上一頁：項目質(zhì)量控制的工具和技術(shù)分析2

下一頁：項目需要現(xiàn)代的管理質(zhì)量

相關(guān)新聞