模板
教程
環境
性能
功能
管理
專家評論: Robert Peterson：防止范圍漸變
什么是范圍漸變？ 定義現實需求的技巧 結束語 僅有 5 到 15% 的企業軟件項目能夠真正實現它們的需求。本文提供了最受歡迎且經過驗證的策略，可以通過這些策略來避免采用面向服務體系結構或企業 Java ? 的企業應用程序發生范圍漸變。這些策略還可能與任何技術
|
什么是范圍漸變？
定義現實需求的技巧
結束語
僅有 5 到 15% 的企業軟件項目能夠真正實現它們的需求。本文提供了最受歡迎且經過驗證的策略，可以通過這些策略來避免采用面向服務體系結構或企業
Java? 的企業應用程序發生范圍漸變。這些策略還可能與任何技術或行業的軟件工程專業人員和架構師相關。 摘自 IBM WebSphere 開發者技術期刊。 什么是范圍漸變？ 項目管理中的范圍漸變（也稱為需求漸變）是指項目范圍的無控制更改。如果沒有正確定義、記錄和控制項目范圍，就會出現這種現象。（摘自 IEEE Spectrum – Why Software Fails） 如果您是軟件工程專業人員、架構師或者項目經理，該主題可能與您密切相關。毫無疑問，任何老練的 IT 專業人員都有這樣的經歷，某些項目的范圍擴大太多，以致最終造成成本和資源大大超過最保守的預期。誠然，盡管對范圍漸變現象沒有萬能良藥，但可以通過一些策略將發生這種情況的可能性降低到最小。 它為什么如此重要？ 如果您是一名開發人員，您可能認為自己僅是向大型組織提供專門技能的代碼管理人員；換句話說，避免范圍漸變的需求應由擔任管理或高級架構角色的人員負責。我希望改變這種普遍的看法，即需求的作用只是形成文檔，僅需 IT 組織中特定角色的人關心就行了。 在我作為 WebSphere 顧問的工作中，范圍漸變是我最為關注的內容。研究表明只有 5-15% 的企業系統在從需求到生產的過程中做到了這一點。企業軟件開發相當困難；例如，需要仔細安排大量的資源、協作和規程才能使華爾街的銀行系統投入生產。盡管我緊跟信息時代的一些前沿技術，如 Web 服務、服務組件體系結構 (SCA) 和 J2EE，但發現我能為我工作的組織帶來最有價值東西的并不是提供多少技術最佳實踐，而是進行風險分析和鞏固需求，這些來得更現實。早些關注范圍漸變，并了解如何使組織防止范圍漸變的最佳實踐，通常是將項目帶入那 5-15% 可靠成功的關鍵。 定義現實需求的技巧 如上面的定義所述，范圍漸變的基本原因時常涉及需求這一主題。如果沒有準確地定義需求，范圍漸變的風險指數將上升。但是，僅僅注意到這一點是不夠的。我曾見過一些雖然非常詳細但卻無助于避免范圍漸變的需求文檔。一種情形是，文檔專家可能在未得到來自開發人員或最終用戶的反饋的情況下編寫需求；而另一種更常見的情形是，專業人員干脆忽略了這些需求——如果這些需求包含在 100 頁的技術文檔中，而且這些文檔又非?；逎y懂，這能責怪他們嗎？ 請考慮下面的建議，以便幫助您開發能夠發揮重要作用的有效需求。 1. 通過測試驅動的開發來鞏固需求 在防止范圍漸變方面，我喜歡的最佳實踐是以敏捷方法為基礎，例如極限編程：在可以將應用程序代碼作為明確的可靠需求之前，對編寫的斷言代碼進行測試。例如，一個較好的測試斷言為 JUnit 測試，即當且僅當 Web 服務返回的 SOAP 信封與預定義的 XML 文檔完全相同時，返回 true。 盡管這是一種定義需求的好方法，容易被開發組織理解，并且可以清楚地驗證軟件系統功能，但單獨的測試用例很少適合作為完整的需求。最適合將測試斷言作為需求的項目是應用程序的最終用戶自己掌握技術的項目。事實上，如果客戶沒有掌握技術，僅使用測試斷言可能很快變成反模式，在這種情況下，可行的測試用例對最終用戶幾乎毫無意義。 例如，使用測試斷言來鞏固需求的理想情形是開發由另一個應用程序調用的組件。假設開發用于訪問遺留系統的自定義 J2EE JCA 連接器，以供工作流應用程序遠程使用。在此情形中，最終用戶很有可能是工作流應用程序的架構師和開發人員，因此使用可執行的測試斷言作為他們與 JCA 連接器開發團隊的需求契約比較合適。 我極力提倡使用測試框架，如 JUnit、httpUnit 和 Cactus。如果您在開發 J2EE 應用程序時常常沒有將 JUnit.jar 放在類路徑中，并按照 JUnit.org Test Infected Tutorial 的說明運行，那么我極力建議您花二十分鐘的時間編寫您的第一個斷言。 2. 使用真實說明最終用戶需求的用例 我的經驗是，大多數企業開發組非常了解需要將用例作為需求過程的一部分，不過他們通常認為用例肯定會帶來麻煩，而且生成的用例文檔在開發過程中提供的價值也微乎其微。帶項目符號的文本對于編寫有效用例幾乎毫無作用。作為技術專業人員，我們有許多工具可用于定義最終用戶的需求。例如，如果用戶是一個使用 Web 門戶的呼叫中心專家，則召開一次會議，專門討論用例將采用哪種形式，并經每個人同意后采用這些用例的內容。對于這種特定的情況，我們建議采用下面這些表示用例的方法： 用戶案例。極限編程需要充當用例角色的用戶案例。這些用戶案例是僅由最終用戶編寫的簡短段落，其中不包含任何技術術語。 難點問題。研究表明，當將難題作為一個問題設計時，將創造一個環境，相關各方可以在一起自由討論可能的解決方案?？紤]提出一些直接來自最終用戶的問題，例如“如何讓以前的客戶呼叫列表顯示在狀態屏上？”可以用例的形式列舉每個問題，并針對相關問題的難點添加上下文。上下文不應包括解決方案或任何技術行話。 流程圖。可以使用 UML 工具或業務流程工具創建流程圖，說明最終用戶業務需求的情形。 用戶界面視圖。作為需求過程的一部分，實現待定應用程序的簡化視圖組件可能非常有效。例如，不帶圖形或高級格式的最基本的 HTML——甚至是白板草圖、簡單的構思圖、紙上的原型圖——可以幫助最終用戶直觀地想象系統的未來模樣。 3. 首先追求實用，然后講究準確 考慮使用迭代或增量軟件工程方法之一。無論組織文化和所選的軟件開發技術如何，實現應用程序的垂直切片（即，關系到預期最終系統中的每個組件的某些功能）可以大大降低風險，并幫助確定影響項目范圍的關鍵問題。然后，可以重構垂直切片，直到滿足最終系統需求為止。支持組件體系結構（例如 J2EE、SCA、JSF 和 Eclipse 插件體系結構）的技術可以大大降低重構的復雜性。 盡管我非常相信垂直切片原則，但正確遵守此原則需要采用許多規程，不會立即完成。在通常情況下，企業系統需要許多基礎服務和必備組件才能使垂直切片發揮作用，這樣會帶來很大的困難。 例如，考慮這樣一種情形，最初的系統開發集中于獲取客戶帳戶。真正正確地實現此功能需要連接到 LDAP 服務器，構建一個面向對象的映射層來抽象數據庫，構造 Web 服務、安全、適當的錯誤處理、無狀態業務邏輯，以便于進行集群和與 CICS 集成等。要構建忠實反映最終應用程序的垂直切片，必須構建最終應用程序所需的每個必要組件和服務，使之能夠有效地進行重構，或者在實現時充分考慮將來的擴展，以便最終發布的系統能夠按原樣使用。您必須采用此規程并說服項目參與者相信此觀點，這是避免范圍漸變的關鍵所在。 4. 有步驟地更改計劃 事實上，組織很少能夠接受系統的最初需求會不斷改變這種可能性。遺憾的是，從傳統體系結構借鑒來的技術常常會在我們的領域導致嚴重的問題：軟件需求不是藍本。在傳統的建筑物結構中，需求通常是固定的；建筑物的大小和位置始終保持不變，一個建筑物不必依賴于另一個建筑物的結構，而且，甚至連小孩也可以一眼看出建筑物的構造狀態。如果將這些確定建筑物構造狀態的方法的準確性與軟件開發項目經理使用的任何度量標準的準確性相比較，則不可避免地存在大量錯誤。由于未預見到項目的復雜性，通常會出現這樣的情況：經評估完成狀態為 90% 的項目需要數年的時間進行額外的開發。 因此，防止范圍漸變的一個關鍵最佳實踐是，在開發過程的任一階段都能夠方便地進行需求更改。沒有必要為了更改某個用例而召開幾十次會議和得到主管的批準。請考慮以下建議： 提供一個過程，以便參與項目的任何人都可以提出改進需求的建議。重要的是，每個人都可以研究需求，每個人都有資格提出更改建議。例如，專門用于項目需求的維基 (Wiki) 或郵件列表在這方面會非常有效。毫不夸張地說，大多數更改管理產品都可以采用 HTML 格式保存項目日程或需求，以便于定期發布。我個人的觀點是，對需求進行編號，并力求簡潔，這樣繁忙的開發人員就可以方便地跟蹤它們。 針對每個步驟獲得用戶反饋。爭取與最終用戶一起舉行檢查點會議，舉行的次數無論如何不可少于與管理人員或其他參與者舉行的會議的次數。如果建議對需求進行更改，則應請求用戶提供反饋意見。 合并風險分析。大多數流行的軟件工程方法都大力提倡對整個開發生命周期進行風險分析。例如，Rational 統一過程要求根據體系結構的影響來確定和跟蹤主要風險因素。與需求跟蹤類似，我極力建議風險分析應簡單明了，讓每個人可以看到并能夠對其進行更新，同時應該根據嚴重程度設定優先級。 結束語 范圍漸變是企業軟件開發中的正?，F象。應該預料到這一現象必將出現，并在軟件開發過程中建立起相應的機制，以對其進行動態響應。但愿在閱讀了這篇文章后，您能夠學到一些有用的東西，幫助您更好地完成工作，同時得到更多的回報和進行更好的控制。 原文轉自：http://www.anti-gravitydesign.com 
|
