在過去兩年內我曾不止一次地說過“軟件工程”的說法是不恰當的，我們實際上操作的是軟件開發。 1 Philippe Kruchtenn 和其它人說區分軟件和其它工程學科主要有兩點：其一是每個軟件開發項目都是唯一的，其二是沒有應用于所有軟件的基本定律。這難道意味著我們應該放棄所有尋找基本定律的希望，以及開發一個更像工程學的方法來開發軟件嗎？
完全不是。軟件仍然是一個年輕的學科，在我們前面仍然有大量基礎和應用研究用于發現它的基本定律。我們同樣需要明白軟件開發的什么部分以及在什么情況下需要遵守更嚴格的方法�？茖W的方法需要我們觀測現象（與軟件相關的），明確表達假設，用那些假設來預言未來的行為，并驗證我們的假設是否是正確的。
如果您在您的軟件開發實踐中應用一個過程，您已經應用了這個科學的方法，至少間接地使用了。讓我解釋一下我表達的意思。
首先，您要觀察您的組織的或者開發團隊的效力。當您看到他們是高效的，但是您認為他們還可以更加高效，您開始思考變化這個過程也許有所幫助。您觀察與軟件相關的現象并開始明確表達出一個假設。
接下來，您要決定運用什么過程。您在這個階段中真正在做什么，這是以先前項目的觀察和經驗為基礎來決定您的過程選擇的。
您選擇了您的過程，因為您想要提高您項目的成功機率。因此您必須有效地闡明關于這個過程功效的假設。
理想情況下，您為您的項目或者團隊來配置過程。當您為您的項目選擇和配置這個過程時同樣要間接地預知您的項目/過程的未來。
現在您必須收集數據并用它來證實您的假設。如果這個假設與觀察到的現象不相匹配，您必須修訂您的假設。有也必須能夠執行預言并且反復驗證，以此來說明這個假設已經并證實了，等等�？芍貜偷慕Y果在這個科學的方法中是十分重要的。
我想詳細考慮一下最后這個步驟——收集數據來驗證這個過程的益處。
讓我們設想您確定，以適合于您的組織的任何一種方式，一個項目是成功的。顯然，您假定您所選擇的過程是這個項目成功的部分原因。您向您的組織發出了關于您成功的消息，并激勵其他人為他們的項目使用您的過程配置，如果他們有類似的項目。您有數據——從成功的項目中收集的——來支持您的主張：這個過程（選擇它是明智的）是形成這個成功的原因�？煽康耐评�，不是嗎？
第二天，您收到執行委員會發來的通知，讓您親自去證實您的主張。您收集您的數據，并給他們一個關于您所收集數據的極好的幻燈片——每一千行代碼中的缺陷率，團隊的生產力等等——非常清楚地顯示了這個項目是絕對成功的。您重復您的主張說，在這個成功中起作用的因素是您選擇了正確過程。
關于這一點，這個主要執行審查人員盯著您問了您一個您不知所措的問題�！澳膱F隊都用這個過程嗎？”您腦海里出現的唯一的回答是“當然，他們告訴我他們都用的，”以及“他們必須使用這個過程因為這個項目是成功的�！蹦庾R到任何一個都不能充分回答這個問題。即使您做了大部分收集項目數據和度量項目的幾個屬性的工作，但是您沒有收集任何關于這個過程使用情況的數據。
的確，這個團隊的成員告訴您他們使用了這個過程，他們真誠地相信他們的確這樣做了。但是那并不意味著他們真的這樣做了，尤其是在這個項目的初始階段，您所選擇的這個過程對于這個組織來說是一個新的過程。他們也許在構建系統方面更加小心，只是因為他們知道您將在他們的執行中收集數據。這只是山楂效應（Hawthorne Effect）的一個例子。 2 因此留下的疑問是：您怎樣知道去度量什么?
度量 Rational 統一過程（Rational Unified Process）
當您執行您的實驗時，您必須收集關于您所使用的這個過程的數據和實驗結果。如果您大力宣揚您的主張，您必須提供足夠的信息證明這個實驗能夠被其他研究人員或者研究團隊來重復試驗。對這個實驗來說，有相同的結果就是正確的。問題又出現了，因為我們經常不知道去捕捉什么數據，在捕捉數據以后，怎樣來分析它。帶著確定您的團隊事實上多大程度上使用了這個過程的目的，這篇文章的剩下部分提出了幾個度量您的過程的方法。如果您可以搜集這些數據，那么您可以確定那些技術在您的環境中是最有效的。
Rational 統一過程?，或者 RUP?，包含了軟件開發各個方面的指導。為了成功地使用它，您必須創建一個適合您的項目的過程配置。絕大多數RUP配置是建立在一系列最佳實踐和其它已經在不同類型的軟件上表明是有效的技術上的。 3
我們的方法十分簡單。我們將選擇一個練習來觀察幾個度量這團隊事實上采取這個實踐的情況的方法。我們將使用 Goal Question Method (GQM)技術 4 。 我們的目的顯而易見。我們想知道，如果這個團隊實際上使用了這個過程，接下來我們的決定將取決于我們將要問的一些問題，這些問題的答案將有助于我們決定能否實現目標。最后，我們將決定使用何種度量方法來回答這些問題。
難道我們不能簡單地問這些團隊成員他們是否使用了這個過程嗎？您可以，我們也能夠這樣問，而且也應該這樣問，但是這些回答將會是更加主觀的而并不客觀。事實上，人們時常會告訴您您想知道的他們在想什么或者他們相信什么是真的，無論那是真還是假。例如，如果您問別人他們怎樣轉到自行車的左邊去，他們會告訴您僅僅將車把轉到左邊自行車就自然而然地轉到左邊了。但是如果他們想一下這個問題，他們將會告訴您他們也可以將自己的身子傾斜到左邊。如果他們十分謹慎地敘述他們自己將自行車轉到左邊，事實上，他們做的第一件事是將自行車車把轉到右邊。 這個小小的移動沒有使他們轉到自行車的左邊，而然后把自行車車把轉到左邊來完成這個轉向。也就是說，他們需要的是經驗主義的數據——基于對這個團隊成員行為的觀察或者我們通過其它方法獲取的數據——這些數據將使我們能夠確定他們是否使用了這個過程以及使用的程度。
我們將看看RUP三個基本的區域：需求管理，迭代開發和測試。有太多的區域或者區域合并需要我們去嘗試并實施。在這篇文章中我們目的是，為了更好地理解我們的過程，我們怎樣選擇一個技巧或者方法，并在其中應用一定的度量方法。
需求管理
絕大多數RUP配置是以用例為中心的。這意味著對于功能性的需求（關于系統必須實際上做什么的需求），我們應當使用用例來描述系統的行為。什么是我們將要問的問題來確認這個團隊是否真正應用了用例并從功能性的觀點來描述系統。 5 出現在我頭腦中的其中一個問題是："在代碼中實現的所有特性 6 都在這些用例中描述到了嗎？"這似乎是非常的直截了當。如果我們能夠識別出實現的這些特性，我們可以將它們與用例中描述的特征進行比較。最大的困難是確定事實上被實現的這些特性。如果我們可以這樣做，我們就可以計算下面用例的度量效果：
假定 F i 是所有被實現特性的數量， F s 是既被實現并且又被特定指定的特性的數量。如果您用100乘以U ，您將得到一個在您的用例中被實現了并實際上也被特定的特性的百分數
具有代表性的是，在您的用例中您所特定的特性將會比您實際上實現的要多。為了及時交付一個可使用的產品，您在管理這個項目范圍時將會刪除一些特性。因此 F s必須僅僅包含那些在您特定的并實際實現的特性�，F在度量數據U的值在0和1之間。如果您完全使用用例作為說明功能性需求的方法，您得到的值將會是1。當您實現了您的用例中沒有特定的一些特性，這個 U值將會減小。
度量數據的唯一問題是，我們如何才能獲得 F s 和 F i? 7 首先，將用例分散到離散的特性中去， F s，并不是很難得到的。 我們能夠檢查用例，并且通常我們同意他們特定的特性。我們可以用場景作為我們度量的一個單元，或者將描述系統行為的每一個步驟作為一個特性。但是更困難的部分是計算 F i。 如果您僅僅測試特定的特性，您可以確定他們是否全部都被實現了，但是您不能確定您的開發人員是否實現了那些并沒特定指明的特性。
讓我們提出一些估計 F i值的方法。一個極好但耗時的確定實現的編碼是否就這個用例中特定指明的方法是，對檢入到項目中的所有編碼實行檢查。這個檢查與您尋找特別的東西有點不同。在這個情況下，您應該盡力的識別已經被代碼實現的特定特性，然后將這些特性映射到用例圖。
第二個確定沒有被特定指明但是已經被實現了的特性的方法是，讓您的測試人員在軟件上執行探測測試。 探測測試是 Cem Kaner和James 發明的技術。 8 。使用這個技術，測試人員不必以一系列測試用例開始，也不用其它預定義的測試腳本。測試人員僅僅需要啟動探測軟件，看它能做什么。測試人員試著確定產品允許他做什么。您可以向測試人員提供用例，讓他們以用例為向導來探測這個產品。當測試人員探測到用例中所沒有的情況，他就把它記錄下來作為實現了但是沒有被特定指明的特性。
我首選的找出 F i值的方法是一個混和方法：
首先，在嚴格基于用例的基礎上運行您的驗收試驗。這些在下一步前必須都通過。 其次，使用代碼覆蓋工具運行您的驗收試驗。被執行的代碼表示了這是實現所有F s所需要的代碼。 最后，檢查您測試中的那些沒有實現的代碼。這些代碼要么是實現了例外條件，要么是實現了但沒特性指明的特性。理想的情況是，這的代碼數量很少，所以也很容易識別出那些未特定指明的特性。
以上的度量數據，U，告訴我們開發人員實現的是否就是特定指明的。但是一個值（特定的）小于1，就意味著這個開發人員沒有很好地完成采取用例驅動開發的工作嗎？也許是在項目執行時用例發生的變化，但是團隊成員沒有盡力去更新這個用例。也許他們依靠一種更加不正式的方法來表達一個新的場景和用例。這將表明實際的過程使用了已經編寫好的、受控的用例來作為一個起始點——這并不一定是一種壞的情形，但是與計劃好的過程有所不同。
當您在您的測試中檢查到并沒執行的代碼時，如果需求發生了變化，但沒有正式地被更新，那么最好的辦法是讓一個人來負責確確認需求。事實上，一個快速檢察它是否是一個問題的方法是，查看您的用例工件的版本控制日志。如果他們在最初的版本之后沒有任何變化，您可以清楚地確定這個團隊沒有保持需求更新，至少在用例中以一種持久的形式使他們保持更新。
迭代開發
任何基于RUP的裁剪的過程，除了大多數小的項目之外，都包含了迭代開發的向導，在迭代過程中軟件是按照迭代的增量式地構建的。通常，最開始的兩次迭代都關注于精化關鍵需求和開發一個可執行的架構。 9 在這些迭代之后，如果還沒有最終完成項目，每個迭代都應當產生一個可運行的系統。
要看我們的團隊實際上是否執行了迭代開發，我們應該問什么問題呢？
迭代的特征之一是嚴格控制時間。 那就是在迭代的開始您可以決定它的終止日期。當這個日期到達時，迭代就結束了。您考慮的僅僅是全部的特性或者您使用什么作為迭代的可交付工件來度量過程。如果一種特性差不多已經完成，但是正好還需要更多一點的工作，但它并不是迭代可交付工件的一部分——也就是說，您不用決定延長迭代的終止日期來適應這個特性。因此您可以這樣問一個問題： "迭代都是有嚴格時間控制的嗎？" 就是說，在迭代的開始它的終止日期就已經確定好了嗎？這是迭代的實際的終止日期嗎？
我們可以用下面的方程式為這個項目的迭代持續度定義一個度量：
假定I m是終止日期已經被修正了的迭代的次數（在迭代開始以后）， I t是迭代的總次數。 如果這個團隊嚴格遵守了迭代的開發過程，我將得到的值是0。在這個可能值范圍的另一個端點，這個團隊在每次迭代開始后，修改了 所有迭代的終止日期。在這種情況下，我將得到的I值是1。 不考慮您是怎樣維持您的項目計劃的，這個度量是十分容易計算的。您所要跟蹤的是您的計劃中日期的變化。
嚴格時間控制的迭代是有必要的，但是要證明這個團隊執行了迭代開發，理由還是不夠充分。我們還需要知道什么呢？另一個我們可能要問的問題是： "在每次迭代結束的時候都會產生一個可運行的軟件嗎？" 您通過計算產生的可運行的軟件來確定您的答案。如果您在每次迭代結束時都將軟件配置存檔，通常是通過在您的版本控制系統中對配置進行標記以及在必要的時候重新構建，這樣您可以在很短的時間內驗證這個軟件的運行情況。
一旦您有了每次迭代的這個信息，您可以計算一個運行軟件的比值，W，如下所示：
假定Iw 是產生可運行軟件的迭代數值， I t 是總的迭代數，跟前面的一樣。當可執行的構架是被第一次產生或者當第一個可執行的軟件開始出現時，您可以選擇調整 I t 為總的迭代數。這樣可以使W的值在0和1之間變化，包括0和1。W 的值越大表明采用迭代開發的程度越高。
測試實踐
測試是您可以在執行活動的正常過程中應用這些度量的區域。您可以容易地跟蹤缺陷發現率和修復率，測試覆蓋統計，等等。您應該能夠開發一些度量來幫助您決定在您的整個過程中，您的實際測試過程是否是已被定義的。
RUP有大量的活動和工件可供團隊來選擇。如果您實行了迭代的增量開發，您的測試應該反應出開發的狀況。這就是說，您應該希望看到第一次迭代產生的測試用例和測試工件，然后隨著系統的增量而增加。
讓我們假設您的團隊的測試過程計劃表明，開發人員所提供的單元測試是針對他們開發的每一個特性的；測試人員將根據需求開發一系列集成和驗收測試，它將測試每次迭代中的運行軟件。再一次，您需要找出這樣的問題，它的回答可以幫助您確定您的團隊實際上是否是根據這個過程進行測試工作的。對我們的例子來說，我們僅僅需要考慮一個問題： "開發人員會單個測試他們的編碼嗎？" 如果您安裝了自動化測試工具，那么所有的單元測試可以從一個簡單的命令開始運行，您就可以很容易地回答這個問題。更值得一提的是，您可以設置您的配置管理系統在任何檢入動作發生時執行測試。
您怎么知道所有的功能都通過了單元測試呢？這個判定是相當困難的。您可以要求每一行編碼都執行單元測試，但是在有些情況下是達不到預期的目標的——也就是說，花更多的精力來開發測試，與這個編碼所帶來的損失比較起來并不值得。我們知道，我們沒有足夠的時間來做所有的事情，因此我們必須根據這個行為的回報來進行優先級選擇。無論什么原因，您確定單元測試的覆蓋率達到100％是不恰當的。在這兒腦子里形成的度量是單元測試的編碼覆蓋率。在每次迭代或者幾次迭代結束時我們可以獲得數據。我們所尋找的是數據的趨勢。我們想知道單元測試在整個項目中是否自始至終都在執行。
讓我們假定我們有12個迭代數據值。圖一中的曲線圖表明三個項目的數據。
圖1：三個項目中12次迭代的測試覆蓋率
從這個數據中，我們可以推斷項目2（圖1中急劇下滑的曲線）很明顯沒有遵循單元測試的過程向導。項目1和項目3似乎很好地完成了這項工作。如果我們認為這很重要，而且有日常數據并有一個更好的圖表，我們可以對它進行更深地研究。圖2中的曲線圖表明了兩個項目中的每天單元測試的數據，如果根據圖1中的X和Y軸看，他們看起來是十分一致的，但是根據有更多坐標點的圖2來看他們卻是十分不同的。我們僅僅看了四次迭代，假定我們有每周的迭代（一周按5天計算）。在這種情況下，項目2在執行編碼時并沒有花時間來開發測試，但是在迭代結束時花了時間來編寫測試。如果這兩個項目在成功之處有所不同——比如，如果項目2比項目1有更差的質量——這提供了一個這樣的暗示：您在追求更高質量時要進行測試。
圖2：在這種情況下，項目2的團隊在執行編碼時并沒有花時間來開發測試，但是在迭代結束時花了時間來編寫測試。
總結
在這篇文章中，我已經為一些基本練習提出了一些的度量方法。但是我認為這篇文章可以幫助您來確定哪些個度量方法更合適您的項目，您因此能夠開發出一個更合理、更容易計算的度量方法。如果您僅僅計劃為一兩個項目獲取度量，那就不必要用這種方法來費心。它不能為您做出有效的推論提供足夠的信息。然而，如果您開始為您所有項目獲取一些關鍵度量，您可以逐漸使之增長成為一個有價值信息的數據庫，根據它您可以應用統計分析。您不需要大量的數據就可以開始分析并詳細闡述關于哪些是有效的哪些不是。您可以，然而需要用一種客觀一致的方法來搜集數據。
管理您的過程并明白它對您的組織是否有效與用科學的方法來進行實踐是相似的。您的目的是能夠選擇并形成一套正確的能有效支持您的項目的技術。您應該為關鍵的實踐識別出一組度量數據，收集必要的數據來確定這個項目團隊是否執行了這個實踐。當您獲得了經驗，增長了度量的數據，您就能夠根據經驗的觀察來調整您的過程。您很快就能夠信心百倍地陳述您的項目團隊中哪些執行了過程，哪些沒有執行過程。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
