對於目前企業應用開發競爭日益激烈，需求變更頻繁，各個系統集成商都面臨巨大的生存壓力。其中有兩個方面表現尤其突出： 沒有統一的軟件開發過程或者照搬重量級的軟件開發過程，例如RUP等，但是往往由於時間等壓力的影響，並不能切實執行；大部分企業仍然沒有擺脫手工作坊期間的做法，每個項目或者產品由於管理人員或者團隊的不同，重新設計系統框架，浪費大量的時間在結構驗證與調整上。
企業應用系統的開發中，需求的變更是項目中唯一不變的東西，而且，為了保持開發的一致性和利益最大化，系統集成商需要與客戶保持長期的合作。因此，采取演進式敏捷軟件開發，可以更好的保證項目質量。在所有的敏捷軟件開發方法中，XP是目前應用最為廣泛的一種。它是一種高度動態的過程，它通過非常短的迭代周期來應對需求的變化；溝通、簡單、反饋和勇氣是它的四大核心價值。同時，它集中了業界的很多最佳實踐，目前已經有18條之多，XP強調通過嚴格執行全部的最佳實踐來獲得"極限"效果。
同時，出於復用和效率的考慮，尤其是對於系統集成商，企業應用系統應該具有自己的框架和結構。擁有具有良好性能、經過項目驗證的系統框架，結合有效的軟件開發過程，系統集成商可以快速、成功地開發企業應用系統。
為了更好的開發成功的系統，系統集成商們可以試著從以下兩個方面著手解決問題： 結合開源工具的支持，在組織內部實施"敏捷軟件開發方法"；為核心業務領域建立靈活、有效的Framework。
由於目前很多企業應用是采用基於J2EE技術的網絡應用程序開發，因此，下面主要介紹基於JAVA的開源項目、工具的應用。
1、開源工具與XP
XP的12條最佳實踐，對於所有的企業應用開發商而言，由於組織和文化的不同，不可能全部應用，但是，下面幾個實踐是有條件逐步實施的：
代碼規范：CODE STANDARD
測試驅動開發：TEST-DRIVEN DEVELOPMENT
日構建：DAILY BUILDING
持續集成：CONTINUOUS INTEGRATION
小步發布：SMALL RELEASE
每日晨會：DAILY MEETING
每周40小時工作：40-HOURS A WEEK
其中，CODE STANDARD和TDD是CONTINUOUS INTEGRATION、DAILY BUILDING和SMALL RELEASE的基礎；而DAILY MEETING和40-HOURS A WORK是單獨的實踐過程，可以與其他的實踐想結合，增強項目小組的溝通，激發士氣。
需要說明的是以上最佳實踐並非XP所獨有，而是被最多的軟件開發方法所應用，其中"日構建"就在微軟的軟件開發方法中正式出現過。
1）代碼規范
雖然大部分的企業在一定程度上推行代碼標准與規范，而且對於使用JAVA的應用程序開發，也有SUN的推薦編碼規范，但是，實際的情況並不理想。
主要的原因在於：一方面，開發人員的習慣勢力很大；另一方面，代碼審查的力度不夠。如果能夠借助工具，從一定程度上幫助進行代碼標准的執行情況檢查，那麼代碼審查就可以著重檢查程序的邏輯和性能等方面。
開源產品CheckStyle (http://sourceforge.net/projects/checkstyle) 可以幫助開發組織解決代碼標准審查的問題。
目前的最新版本為3.0，它提供了兩種運行方式：一種是命令行；一種是與Ant結合(Ant自1.5以後提供的OPTIONAL TASKS中有對於CheckStyle的支持)。同時，SourceForge中有對於JBuilder等流行IDE的插件支持，可以定義Global、Project級別上的屬性文件， 但是，目前只是支持2.42版本。
在3.x版本之前，CheckStyle的配置信息寫在Property File中；而在3.x之後，配置信息為XML文件，配置更加靈活。3.0的發布版本中提供了針對Sun Code Conventions的特定Check File，可以參考使用。
建議執行情況：
手動執行：開發人員在IDE中手動觸發CheckStyle檢查或者代碼審查時由審查者手動執行；
自動執行：將CheckStyle與源碼控制系統(CVS)結合，在源碼Checkin的時候進行規則判斷，如果不符合，則不允許代碼進入系統。
2）測試驅動開發
測試先行或者測試驅動是XP的基本實踐之一，同時測試在軟件開發中的重要作用正越來越得到人們的重視。審查和測試作為系統確認和驗證的有效方式，是項目質量保證的重要措施。
下面按照一般的測試分類，介紹各個領域內的開源測試工具：
單元測試：JUnit (http://www.junit.org)
JUnit是由 Erich Gamma 和 Kent Beck 編寫的一個回歸測試框架（regression testing framework），用於Java開發人員編寫單元測試之用。下面介紹的開源測試工具，很多都是對於JUnit的擴展。
它目前的版本為3.7，為編寫單元測試提供了主要的接口。目前主流的IDE都提供了對於JUnit的支持。
XP強調測試先行，尤其重視單元測試。系統集成商需要通過軟件開發過程的執行，來強化JUnit的使用。
目前很多商業測試軟件都提供了與JUnit的聯合使用，例如獲得1999和2000年Jolt測試類工具亞軍和生產率大獎的Jtest (ParaSoft公司產品，內置200余條編碼規范，提供Java代碼靜態和動態檢查，同時還可以自動生成簡單的測試用例等等)就可以導入和導出JUnit的測試用例。
集成與功能測試：HttpUnit (http://unit.sourceforge.net) & Cactus(http://jakarta.apache.org/cactus/)
HttpUnit是一套通過HTTP連接測試Web應用程序的Java類。在結合JUnit的情況下，HttpUnit可以作為一種創建測試程序的強大工具用來保證Web應用程序正常的端對端功能。
雖然JUnit自身就可以通過編寫單一類的測試程序對服務器端Java代碼進行測試，不過，有了HttpUnit的幫助，JUnit就可以擴展為模擬Web浏覽器-Web服務器的工作方式對整個Web程序結構進行測試。
Cactus為我們提供了一種測試SERVLET等WEB組件的有效手段。它是JUnit的一個擴展，但是它又和JUnit有一些不同。Cactus的測試分為三種不同的測試類別，JspTestCase， ServletTestCase， FilterTestCase， 而不是像JUnit就一種TestCase。Cactus的測試代碼有服務器端和客戶端兩個部分，他們協同工作。
一般意義上，可以采用Cactus作集成測試；而使用HttpUnit做功能測試。
雖然在集成與功能測試方面，有很多優秀的開源工具，但是在實際應用過程中，還是采用商業測試軟件的比較多，對於復雜應用更是如此。這是因為集成與功能測試大部分還是由專門的測試人員進行，而他們對於已有的商業軟件，例如Rational Robot、E-Test Suite、WinRunner等都比較熟悉，同時商業軟件也提供了更為強大的功能。
壓力與性能測試： JMeter (http://jakarta.apache.org/jmeter/)
由於企業應用越來越復雜，用戶數量也是越來越多，系統的性能參數以及眾多的非功能性需求在開發中獲得了越來越多的重視。因此，很多壓力與性能測試工具也開始出現，這其中有一定影響的是Apache Software Foundation的JMeter。
JMeter是100%的JAVA桌面應用，用來測試系統的負載與性能。它最開始設計是用來測試WEB應用，後來加以擴展，可以測試Http，FTP，支持JDBC的關系型數據庫的性能與壓力。同時，JMeter提供一定的定制功能，系統集成商可以自行開發針對EJB、CORBA或者SOAP的插件。
壓力與性能測試方面，由於測試比較復雜，實際企業應用測試中，也是采用商業測試軟件比較多，例如LoadRunner、JProbe Suite以及與JBuilder8 同步發布的OptimizerIT；
3）日構建
在軟件開發的領域裡有各種各樣的"最佳實踐"，它們經常被人們談起，但是似乎很少有真正得到實現的。這些實踐最基本、最有價值的就是：都有一個完全自動化的創建、測試過程，讓開發團隊可以每天多次創建他們的軟件。
"日創建"也是人們經常討論的一個觀點，McConnell在他的《快速軟件開發》中將日創建作為一個最佳實踐來推薦，同時日創建也是微軟很出名的一項開發方法。但是，我們更支持XP社群的觀點：日創建只是最低要求。一個完全自動化的過程讓你可以每天完成多次創建，這是可以做到的，也是完全值得的。
Ant是Apache Jakarta的一個項目，是"不帶 make 缺點的 make"。Ant 正在成為開放源代碼世界中實際上的標准。原因很簡單：Ant是使用 Java 語言編寫的，這種語言可以讓創建過程在多種平台上使用。
Ant目前的版本為1.5，它的執行是基於一個XML文件，配置文件由目標樹構成。每個目標都包含了要執行的任務，其中任務就是可以執行的代碼。在下面給出的例子中，mkdir是目標compile的任務。mkdir是建立在Ant中的一個任務，用於創建目錄。Ant 帶有一套健全的內置任務，也可以通過擴展 Ant 任務類來添加自己的功能。
Ant內置了對於JUnit、CVS、ClearCase、Visual SourceSafe以及CheckStyle的支持，通過於系統定時功能，例如Windows的"任務計劃"或者Linux/Unix的"cron"，可以很方便的利用Ant來自動完成每日構建的工作。
4）持續集成
持續集成是XP的重要實踐之一，Martin Fowler在參考文獻[6]中有詳細的介紹，上述實踐都是它的基礎。
開源項目中有一個著名的工具是用來幫助實現持續集成的：CruiseControl，其次，目前還有一款商業軟件AntHill也為持續集成提供了很好的支持。
CruiseControl (http://cruisecontrol.sourceforge.net/)
CruiseControl是著名的ThoughtWorks公司的產品，目前它的源碼已經公開，它是一個持續集成的框架。它包含，但是並不局限於Email通知、Ant以及其他源碼控制工具。同時，它還提供了WEB界面來查看當前和已往Build的詳細信息。
AntHill (http://www.urbancode.com/projects/anthill/)
AntHill可以確保Build過程受控，同時，幫助組織內部的知識共享。它在每次Build之前從源碼控制系統 (CVS、VisualSourceSafe、ClearCase等)中獲取最新的源碼，同時在Build完成之後為源碼分配一個唯一的數字進行標定。同時，它還會在根據Build的情況，更新Intranet的信息。
5）小步發布
有了以上實踐的支持，小步發布就有了實現的可能。XP強調在非常短的周期內以遞增的方式發布新版本，從而可以很容易地估計每個迭代周期的進度，便於控制工作量和風險；同時，也可以及時處理用戶的反饋。
為了成功的進行應用系統的版本發布，需要SCM，尤其是源碼控制程序的配合。在開源項目中，CVS (Concurrent Version System)是最著名的版本控制程序。
目前CVS的版本為1.5.11，它是一個將一組文件放在層次目錄樹中以保持同步的系統。人們可以從CVS服務器上更新他們的本地層次樹副本，並將修改的結果或新文件發回；或者刪除舊文件。CVS 基於客戶端/服務器的行為使得其可容納多用戶，構成網絡也很方便。這一特性使得 CVS 成為位於不同地點的人同時處理數據文件(特別是程序的源代碼)時的首選。所有重要的免費軟件項目都使用 CVS 作為其程序員之間的中心點，以便能夠綜合各程序員的改進和更改。
基於多個操作系統的CVS的客戶端軟件也很多，其中以WinCVS最為著名。
2、開源項目與Framework：
目前，對於基於J2EE的應用程序開發，有很多開源的Framework，例如Struts (http://jakarta.apache.org/struts/)、WebWork等，都提供了利用J2EE技術的優秀解決方案。其中，Struts是目前應用最為廣泛和獲得關注最多的框架之一。
Struts目前的版本為1.1，它是基於Model2的MVC實現框架。Struts的核心是基於Servlet、JavaBean、ResourceBundles和XML技術的控制層。
還有很多開源項目為Struts提供支持，例如：
配置文件GUI：Struts Console；
Code Generator：Easy Struts；
Unit-Test：StrutsTestCase；
獲得2002年JAVA IDE大獎的JBuilder 8更是內置了對於Struts的支持，這也從另外一個側面體現了Struts的重要意義。
同時，需要注意的是，Struts本身並沒有提供Persistence層的標准實現，但是，目前這個方面的解決方案比較多，系統集成開發商可以根據具體情況加以選擇。
如果可以在Struts等Framework的基礎上，結合不同業務系統的專業知識，開發獨立的系統平台，系統集成商的項目開發速度和質量都會有很大的提高。
