模板
教程
環境
性能
功能
管理
需求版本化
|
背景
方法1：包括一切
一個新的需求屬性
例子
方法2：利用一個變更請求管理器
例子
表2：使用變更請求管理器的例子
一個現實的場景：這種情況在你的身邊發生過嗎？
結論
本文來自于 Rational Edge：作者提出了兩種用于跨多個產品發布版本場合管理需求的多個版本的方法。第一種方法使用了IBM
Rational RequisitePro 或者其它需求管理工具。第二種方法使用了變更管理工具，例如，IBM Rational
ClearQuest，它可以與需求管理工具結合使用。 這就產成了一個有趣的管理問題。在一個大的系統中，可能有許多需求，數量多得使我們很難在適當的時候記得去變更需求。理想情況下，當一個分支被合并時，需求就被正確地更新了。對受此需求影響的測試的跟蹤應當被認為是可疑的，這樣測試人員會自動地得到通知，測試用例可能也需要進行變更。 在本文中，我提出了兩種處理此問題的方法。 人們可能認為實現文件版本化的軟件配置管理（SCM）工具，比如 IBM Rational ClearCase，會滿足這種需求。不幸地是，像這樣的版本控制能力不適用于這種要求，除非我們嚴格地將一個需求放在一個文件中，并且為每一個需求都維護一個單獨的文件 —— 這其實是十分不實際的！許多需求管理工具為每一個需求都保持了歷史記錄，但是并不能實現版本化。由這些工具提供的關于需求的完整視圖僅僅是“Main/Latest”。 以前我們已經嘗試了好幾種方法來處理需求版本化，包括復制需求庫和將需求文檔復制到包含需求文本（其缺少屬性和跟蹤信息）的臨時文檔中。這些方法都不令人滿意。要么是勞動密集型的并且容易出錯，要么削弱了成功管理需求所需要的需求工具特性，而這些特性是為了應對市場影響或者其它因素而做出改變所需要的。 讓我們考慮一下跨多個產品發布版本來維護對需求變化的可追溯性的兩種方法。第一種技術利用了 IBM Rational RequisitePro，第二種則同時使用了 RequisitePro 和 IBM Rational ClearQuest。這兩種方法都通過一種簡單的原則來描寫這些需求，只包括產品的基本特性。雖然我們使用了IBM Rational產品，但這些方法也應該可以擴展到其它擁有類似能力的產品中。 第一種方法依賴于一個簡單的原則，它擴展了如何定義需求的傳統規則。目前，普遍應用于需求定義的規則很少。唯一保持一致的規則是通常被稱作為 Zen Rule 的規則：一個需求必須是對所需要的某件事物的陳述。為了改進這個方法，我們需要擴展我們需求的范圍：一個需求必須總是描述那些在任何時間點上被需要的事情，不管是現在還是可預知的將來（只要在我們知道的范圍之內）。除了使我們的方法更容易之外，這個新的范圍也是有價值的，因為這樣的需求變成了在整個過程中我們需要了解的所有基本需求的詳細敘述。這對系統的構架和設計的幫助都是很有意義的。 例如，我們假設一個系統的需求是在下一個發布版本中需要四個窗口部件，而再下一個發布版本需要6個窗口部件。然后，我們的方法表明這個需求應該這樣描述一個完整的需要：SUPP42: XYZ 應用程序將在2006年6月30日的發布版本中包含四個窗口部件，而接下來的發布版本中將有六個窗口部件。 注意，這并不意味著我們在更新需求時一定要包含過去的信息。從需求分析的角度來看，如果2006年7月1日我們碰巧去變化了需求，讀到以下的信息：SUPP42：XYZ應用程序將有6個窗口部件，這樣是沒什么問題的。如果我們這樣做了，那么對于 SUPP42 來說，先前的需求版本應該被儲存在 RequisitePro 的歷史記錄中，并且它也仍然是可以訪問的。更重要的是，在下面所描述的機制將告訴我們一個變化已經發生了。 為了改進這種方法，我建議對每一個需求類型增加一個新的屬性，這些需求可以被基于多版本的發行版本使用?？梢詫⒋藢傩苑Q為版本評審日期（Versioning Review Date）。當一個需求分析師因為版本控制的目的要評審需求文本時間時候，我們會為每一個需求定義一個新的的Versioning Review Date 屬性。當它是空白時，說明此需求當前沒有必需被評審。任何在時間上其描述與多個狀態相關的需求，都應當被需求分析師分配一個日期值。Versioning Review Date 應當與分析師期望需求的某些部分將會變化或者作廢的時間一致。 下面這個例子闡述了“包含一切（all inclusive）”的方法是如何使用的。表1中的第一列中記錄了每一行所顯示的變化日期。Versioning Review Record 一列中表明了一個變更請求是否是打開的，如果是，那么它還包含著Version Review Date 記錄屬性的值。Requirement Text 一列顯示了需求的當前文本。Test Case 列保存了補充需求的值，這些需求將通過測試用例來測試。 藍色的箭頭表示一個追蹤，紅色斜向下的箭頭表示一個可疑追蹤。由于有其它適當的成對的需求與測試用例，分析師之前并已經注意到（通過被叫作可追蹤性）這個需求與這個測試用例是有聯系的。這種關系很簡單：如果其中的一個變化了，另一個也會變化，因此從分析師的角度來看應該關注這個問題。需求管理工具注意到需求已經變化了。因此這樣就使追蹤值得懷疑，表明這個測試用例值得注意。我們的方法當中的一部分就會對可疑追蹤進行定期地詢問。它們包括一個早期報警系統，以此來確保變化對需求的影響可以跨過產品版本被分析，并在需要的時候被處理。 最后，只需要使事情保持簡單，讓我們假定這個應用了樣例需求的應用程序已經有了三次發布：8月31日，9月30日和10月31日。 表1：“包含一切”方法的例子
這個替代的方法是對以上描述的“包含一切”方法的變種。它利用了IBM Rational ClearQuest 的可用性，或者其它任何支持需求追溯性的變更請求管理器。這種方法有以下三個基本步驟： 我們書寫需求，以便它們總是能夠描述在任何時間上被需要的事情，正如“包含一切”的方法中的一樣。 當然，這里的好處是不用有人必須記得要在需求管理工具中運行查詢，來看什么需求應該接受一個版本控制的評審。變更管理工具現在卻包含了這些信息。 表2顯示的這個例子中，第一列中記錄了每一行所顯示的變化日期。Versioning Review Record 表示一個變更請求記錄，其包含了對每個被追蹤需求的評審日期。其余的列保存著與前一個例子中的表1相同的信息。值得注意的是通過這種方法使用變更請求可以簡化后續的工作，因為一個記錄可以表示變更了許多需求的需要。 此外，假定這個應用了此需求的應用程序已經有了三次發布：8月31日，9月30日和10月31日。
由于一個國防應用軟件，Ephemeris Information Systems Inc（不是公司真正的名字）延遲了新的 Ephemeris Database 的開發周期，這個數據庫是與跟蹤地球軌道上許多人造衛星的信息相關的。跟蹤太空垃圾與活動的衛星對在太空中的任何空間活動都是很重要的，并且無人航天器也是相當昂貴，如果它們與太空的其它物體相撞，將會導致一場災難。數據的測試進行得很順利。尤其是對于特殊屬性（讓我們暫且稱之為 Cheese 吧）的查詢進行得很快，測試表明對這個屬性的查詢情況是，稍微超過了任務設計說明書的指標。 一天，從事于這個程序的測試人員注意到，一個說明了 Cheese 屬性可能值的需求最近已經變化了，不再是兩個字節。上升到八個字節就應該存儲這些可能值。關于是否有變更計劃的必要還沒有決定下來，因此他還不能構建并執行適當的測試，他找到他在開發工作室的朋友問他這個需求變化是否已經被注意到了。 這個開發人員看起來十分驚恐，她問是誰做了這個變更，并拿起電話問分析師：“我們先前怎么沒有聽到關于 Cheese 變化的事呢？”這個分析師回答說，“我們起初也不知道這個值會那么大，所以最初的需求僅僅只有兩個字節。但在項目開發開始之后不久，我們才知道需要更大的值，但是我們知道原型是事先已經構造好了的，而且兩個字節對于那個原型已經足夠了，所以我們就把這個需求擱置一邊。不幸的是，我們直到最近才記得做這個變更，我們只是忘了?！?/p> 這個開發人員說了謝謝就掛斷電話。接下來的幾天，他們作了各種嘗試，但是沒有人能夠找到一個辦法解決這個正在籠罩整個項目的問題。這個開發人員擔心的最糟糕的事發生了。在兩個字節的時候，這個數據庫自動緩存了大量的 Cheese 值，其產生的查詢性能是可接受的 —— 查詢性能超過了需求所需要的35％。然而，在開發前期，他們已經意識到如果 Cheese 的值超過了四個字節，將會需要一個完全不同的數據庫組織方式，一個不同的數據表結構（schema）來達成所需要的性能?！班?，Cheese 值決不會超過四個字節”，有人這樣說。事實上，大家已經知道在某些情況下，將會達到八個字節。項目開發采用更容易實現的數據表結構繼續進行著，因此兩個星期的時間內將會遇到更多困難，但是可能不需要兩個星期，計劃就會被解救。 現在，隨著更復雜計劃的需求漸漸明了，更長的開發時間將會花在為舊的 schema 構建數據轉換上，幸運的是，在良好的子系統的設計中，查詢管理是獨立的，因此為新的 schema 重新設計查詢的花費不會太高。然而最后，在某些事情變得更復雜的時候，新的 schema 是更好的數據架構的組成部分之一，使得后來處理程序中所發生的許多來自用戶的無法預料的變更變得更加容易了。 總之，兩個需求 —— 一個僅僅針對早期的迭代，一個對后來的產品系統是必要的 ― 應該事先都了解清楚。原型開發總會使成本略高一些，但是團隊可以檢驗一個更復雜，但卻更被需要的數據架構，這會很快在得到高性能查詢中顯示其價值。 需求版本化是一個過程，其記錄了對特定需求隨著時間進行多次變更的所預期的需要。對于大多數項目，實施需求版本化最好的原因是使團隊能夠準確地確定一個需求如何，以及為什么要從一個發布版本變更到下一個發布版本，因此測試用例也可以相應地被修改。需求版本化也簡化了需求審計的功能，有助于確保產品滿足需求，并因此改進質量。最后，它可以使構架人員和設計人員能夠看到完整的最終系統范圍，改進架構和系統設計的健壯性。 正如以上方法和相應的例子所闡述的一樣，對于開發團隊來說通過使用現有的工具來實現需求版本化是非常簡單的，這只需要改變一下需求編寫的方式，并添加一些新的流程。 原文轉自：http://www.anti-gravitydesign.com 
|
