極限編程在開發(fā)供電客戶服務監(jiān)控系統(tǒng)中的應用

1、極限編程在開發(fā)供電客戶服務監(jiān)控系統(tǒng)中的應用 林鵬程，王默玉 （華北電力大學計算機科學與技術系，北京 102206）摘要：針對傳統(tǒng)軟件編程的缺點，詳細介紹極限編程思想的核心內容和意義，并且闡述了該方法應用于開發(fā)供電客戶服務監(jiān)控系統(tǒng)。一、引言進行開發(fā)軟件過程中，必須考慮到各方面的因素，軟件需求可能會發(fā)生變化，這些變化會包括質量、整體、范圍、進度、人力資源、成本、溝通、風險、環(huán)境等方面的因素。若采用傳統(tǒng)的軟件編程方法，需求的變化可能會引起后期進行軟件設計的重大變化，輕則造成成本的指數(shù)上升，重則使整個軟件在整個設計中面臨失敗。為了尋求迅速建立軟件途徑并適應不斷變化的用戶需求，克服許多公司的軟件團隊陷入

2、不斷增長的過程的泥潭，美國軟件工程大師Kent Beck等人，在“敏捷聯(lián)盟”中提出了一種創(chuàng)新的軟件工程設計方法極限編程（Extreme Programming 簡稱XP編程）。Xp編程是一種輕量級的、靈活的編程方式，自身規(guī)定了核心價值和方法，強調溝通和反饋，整個設計過程由一系列簡單卻互相依賴的實踐組成，在理念、管理和項目計劃方法等方面和傳統(tǒng)的軟件開發(fā)過程不同。二、極限編程2.1 傳統(tǒng)軟件設計模型如圖1所示，傳統(tǒng)軟件設計中規(guī)定了各項軟件工程的活動包括：制定系統(tǒng)計劃，進行詳細需求分析和說明，實現(xiàn)編碼，對系統(tǒng)進行測試。整個設計規(guī)定了自上而下，相互銜接，如同瀑布一樣將各個不同階段串聯(lián)起來，并用文檔提交

3、來驅動下一個環(huán)節(jié)，常有許多規(guī)則和文檔，要正確的實施它，在開發(fā)流程上有較高的要求。該模型最大的缺點是：缺乏適應需求變化的靈活性，更改程序的成本會隨時間的推移而呈指數(shù)方式上升；而且對進度的估計經常容易失誤，可能導致工期的延長，因而要付出高額代價來返工或者在維護中糾正錯誤。需求分析需求分析設計編碼測試圖12.2 Xp編程的設計模型簡單來說，極限編程是一個高迭代的過程，在控制論（Control Theory）中，迭代過程可以不斷向系統(tǒng)提出反饋，以確保得到預計的最終結果，而在Xp編程中，將需求分析的時間大大縮短，之后的開發(fā)中4個活動（需求、設計、編碼、測試）同步進行，每一次迭代都是建立在上一次迭代的基礎

4、上進行，其開發(fā)模型如圖2所示。需 設 編 測需 設 編 測求 計 碼 試圖22.3 Xp編程的核心思想要達到高迭代過程，開發(fā)組中必須具備以下四種不同的思想：溝通（Communication）、簡單（Simplicity）、反饋(Feedback)和勇氣(Courage)。Xp編程認為開發(fā)組不只是包括開發(fā)人員，還包括客戶和管理人員，強調成員間要經常進行交流。盡量減少在關鍵性的領域決策出現(xiàn)嚴重失誤；開發(fā)人員應當在進行當前階段設計，力求以簡化的方式完成已知的工作，待在以后階段中，如有必要再做修改，避免將資源花費在復雜而又不符合客戶真正需求的程序中；對系統(tǒng)當前的狀態(tài)不斷的進行反饋，反饋要以不同的時間進

5、行，以便提供更多的機會來調整設計，保證把握正確的方向；對于以上的這些思想，一旦發(fā)現(xiàn)錯誤，要勇于對自己的代碼進行修改，才能符合Xp編程所提倡的“擁抱變化”。2.4 Xp編程的實踐方法 主要包括：（1）小版本：符合需求的前提下，經過了一個或幾個迭代周期后，向客戶提供一個版本，通過頻繁發(fā)布小版本，從客戶中得到更多的反饋。 （2）規(guī)劃策略：客戶負責編寫系統(tǒng)需求（Xp稱為素材），程序員對每個素材所需要的開發(fā)時間做出估測，客戶根據(jù)所估計的時間為基礎，決定素材的優(yōu)先級。通過以上活動開發(fā)人員可以迅速得到粗劣的計劃，規(guī)劃策略不是只進行一次，每次迭代完畢后，都要重新修正。 （3）現(xiàn)場客戶：為加強同客戶之間的交流，

6、建議在開發(fā)過程中有一個客戶隨時與開發(fā)人員一起，現(xiàn)場隨時向開發(fā)人員提供其業(yè)務需求，素材的優(yōu)先級及其其他相關信息。 （4）系統(tǒng)比喻：為了讓所有項目參與人員對系統(tǒng)有一致的理解，將系統(tǒng)設計制定一系列的比喻來表達系統(tǒng)的輪廓、工作和組織方式。（5）簡單設計：開發(fā)人員使他們的設計盡量簡單，滿足計劃在本次迭代中要完成地用戶需求，而不用考慮未來地用戶需求，因為在每次的迭代中，系統(tǒng)設計不斷的優(yōu)化，使之正在實現(xiàn)的用戶需求保持在最優(yōu)狀態(tài)。（6）重構：在不改變代碼所要完成的任務前提下，對其進行一系列的小改造，重構是持續(xù)進行的，而不是在項目結束時、迭代結束時才開始。通過重構，可以持續(xù)保持盡可能簡單并且具有實用性的代碼。（

7、7）測試驅動開發(fā)：先編寫測試用例，再編寫所有代碼。由于要測試的功能還不存在，所以會運行失敗。為了讓使失敗的單元測試能夠通過，開始編寫代碼。這樣做會確保更改沒有對程序造成任何破壞，且有利用重構，降低各個模塊間的耦合度。（8）持續(xù)集成：程序員在獨立開發(fā)后，要進行系統(tǒng)集成。程序員完成對模塊的修改后拆入回去，所做的改動應該和在他前面拆入該模塊的程序員做的改動進行合并。（9）結隊編程：所有代碼都需由結對的程序員使用同一臺電腦共同完成。結對人員中的一位控制鍵盤并輸入代碼，另一位觀察代碼并尋找代碼中的錯誤和可以改進的地方，兩人頻繁互換角色，強烈的進行交互。（10）代碼共有：任何人在任何時候都有權對源代碼做出

8、修改，以增加新的功能、除錯或進行重構。（11）編碼標準：為了實現(xiàn)代碼共有的目的，必須建立一個所有人都遵守的編碼標準，增強程序的可讀性和可維護性，方便整個小組的工作。（12）每周40小時工作制：極限編程不贊同長時間的工作，過長時間會引起錯誤率上升，不能保證高質量的工作。這12個實踐活動在我們以往的編程實踐中已經用上了，因此不是獨創(chuàng)。在Xp編程中，這些活動是相互支持，才能達到極限編程所體現(xiàn)的原則。2.5 Xp編程的活動過程如圖3所示，在開發(fā)過程中，用戶進行需求分析，同時設計出測試場景，需求分析結合原型結構。運用系統(tǒng)比喻，得到了計劃版本，這些版本對所做的用戶需求不做深入的設計和細節(jié)的開發(fā)，而只是提供

9、用來可完成的估計時間，按照這個時間進行“設計、編碼、測試、發(fā)布”4個過程進行，任何一個過程出了問題，立即回饋到計劃版本中進行迭代。經過了開發(fā)人員編碼實現(xiàn)并測試后，當前版本就可以發(fā)布，然后轉入下一個版本，逐步形成最終的發(fā)行版本。與發(fā)行版本相關最重要的任務是使計劃版本用戶在開發(fā)人員的指導下，從需要實現(xiàn)的需求中選擇最有價值并完成一定功能的最小素材集。用戶滿意 待定 確定評估 評估計劃版本迭代小版本原型分析系統(tǒng)比喻發(fā)行計劃最新版本驗收測試用戶素材測試場景原型結構需求 新需求 錯誤下一次交互迭代是指通過一定的迭代規(guī)劃，將用戶若干素材分成若干任務，重復進行“編碼、測試”，添加到當前版本中去，最后發(fā)布。迭用

10、戶滿意 待定 確定評估 評估計劃版本迭代小版本原型分析系統(tǒng)比喻發(fā)行計劃最新版本驗收測試用戶素材測試場景原型結構需求 新需求 錯誤下一次交互圖3 極限編程活動圖三、極限編程在“供電客戶服務監(jiān)控系統(tǒng)”的應用在開發(fā)“供電客戶服務監(jiān)控系統(tǒng)”中，由于該系統(tǒng)的需求不能完全確定，系統(tǒng)的測試又要求比較高，所以采用了Xp編程的方法。系統(tǒng)的主要功能模塊為工作簡報、業(yè)務匯總、人員管理、常見問題四個模塊，其模塊功能分布如圖4所示。工作簡報模塊，主要包括滿意率簡報、簡報列表、簡報管理三個子模塊。通過滿意率簡報能夠按條件查詢客戶對各地的滿意程度，簡報列表能夠及時了解每天各地的工作情況，簡報管理模塊提供了對工作簡報進行維護

11、功能，以方便工作人員進行操作和管理。業(yè)務匯總模塊，對各供電公司的服務業(yè)務進行統(tǒng)計匯總，服務業(yè)務包括：綜合統(tǒng)計查詢、業(yè)務量統(tǒng)計、話務量統(tǒng)計、故障明細統(tǒng)計、投訴明細統(tǒng)計、歷史業(yè)務統(tǒng)計。該模塊將各地市供電公司的各種業(yè)務按照“新受理”、“已處理”、“累計結存”進行匯總，統(tǒng)計。人員管理模塊，對使用系統(tǒng)的人員進行同一管理，主要包括操作人員管理、權限管理、密碼修改等功能。主要功能實現(xiàn)維護用戶信息、為用戶分配權限等功能。常見問題，針對系統(tǒng)使用常見的一些“故障”問題進行回答，并可以通過此模塊了解系統(tǒng)的功能及使用方法。這些系統(tǒng)需求，具體細節(jié)不能在短期內確定。由于各地供電系統(tǒng)客戶服務提供的情況不一，給出的查詢條件限

12、制無法立刻統(tǒng)一確定，簡報列表提供具體圖狀顯示結果，在開發(fā)初期沒有考慮；故障和投訴表收集和處理，需要明細表結構，如何進行分類處理，定義幫組信息必須和用戶進行頻繁交流；在累計結存過程中，需要不斷進行數(shù)據(jù)測試，保證數(shù)據(jù)結果的可用性。供供電客服監(jiān)控系統(tǒng)工作簡報業(yè)務匯總常見問題人員管理滿意率簡報簡報列表簡報管理話務量統(tǒng)計故障統(tǒng)計投訴統(tǒng)計業(yè)務量統(tǒng)計信息管理權限管理幫組信息問答留言圖4 供電客戶服務監(jiān)控系統(tǒng)總體需求圖SHAPE * MERGEFORMAT鑒于上述情況，在本項目中，我們借鑒極限編程許多思想和方法，采用了如下工作方式：（1）開發(fā)小組由7人組成，7個人集體參與需求分析和設計，而并不是由項目負責人獨

13、立進行，同時在開發(fā)過程中隨時聽取用戶意見，力求及時準確理解客戶需求。（2）在具體實施中，開發(fā)小組分為兩組：業(yè)務組和技術組。業(yè)務組負責明細模塊中的函數(shù)接口，定義函數(shù)功能；技術組負責編寫代碼，主要負責編碼的規(guī)范和為自己所的代碼編寫測試用例，在編碼過程中，業(yè)務組和技術組進行結對編程。最后由一人負責幫組客戶完成功能測試，最終所有測試由客戶認可。（3）由于項目開發(fā)時間短，我們在開發(fā)中簡化了設計文檔，但對于測試文檔和測試用例，提交到項目負責人中進行嚴格審核。（4）統(tǒng)一的編程風格，包括變量的定義、函數(shù)的接口、文件命名的規(guī)范、文件類型的定義等。（5）每天工作8小時，每天工作結束時，通過CVS工具提交當天所完成

14、的代碼和測試用例，并且通過該工具每個人都了解和熟悉其他成員的工作進度，且可以進行及時的調整進度。在版本規(guī)劃階段中，我們通過與客戶交流，共同決定了6個發(fā)行版本，如表1所示，根據(jù)這個規(guī)劃逐步編碼，在編碼過程中不斷與用戶交流，使用戶逐步完善需求。表1 版本規(guī)劃表版本 開發(fā)時間（單位：天） 功能實現(xiàn)V1.010工作簡報原型：顯示簡報列表，對該表進行管理業(yè)務匯總原型：處理話務量、投訴、故障狀態(tài)信息，實現(xiàn)數(shù)據(jù)庫導入導出操作V1.115完善數(shù)據(jù)導入功能。對工作簡報進行滿意率簡報管理，能按條件對各地信息進行查詢；對業(yè)務匯總模塊實現(xiàn)業(yè)務量統(tǒng)計，并且可以進行業(yè)務查詢。V1.210對于人員管理，用戶、管理員信息管理

15、，操作權限設定；在常見問題中，實現(xiàn)問答留言功能。V1.35編寫基本幫組信息，完善輸出界面，發(fā)行最終版本。四、結束語極限編程由于自身的特點，它適用于幾人的小項目組，不適用非常大的項目團隊，但是許多思想可以被其他開發(fā)方法借鑒；在國內也很難嚴格遵循它所有的12個實踐方法，但可以根據(jù)實際情況來調整和使用極限編程。實踐證明：極限編程能靈活應對需求變動大和測試要求高的開發(fā)案例，目前我國電力行業(yè)正走向信息化，許多開發(fā)團隊大都是非電力行業(yè)專業(yè)人員或對電力行業(yè)知識理解不深的人員，應用極限編程提倡與用戶直接交流，能夠保證需求理解的正確；并且通過迭代編程的思想來發(fā)行多個版本，開發(fā)人員和用戶能在較短的時間內獲得理解正確的功能，大大加快了軟件的開發(fā)時間；極限編程重視測試，能很好的提高了軟件的質量。因此，恰當運用極限編程，能提高我國電力行業(yè)軟件的質量和我國軟件行業(yè)的競爭力。參考文獻1Kent Beck著 解析極限編程-擁抱變化M北京：人民郵電出版社，20022Kent Beck著 規(guī)劃極限編程 M北京：人民郵電出版社，20023雷劍文，陳振沖等著 超越傳統(tǒng)的軟件開發(fā)極限編程的幻象與真實M北京：電子