| 本文以一個PRM項目為例， 探討了目前國內(nèi)軟件開發(fā)企業(yè)在軟件開發(fā)過程中，尤其是企業(yè)應(yīng)用系統(tǒng)項目開發(fā)中，面臨的問題以及如何利用敏捷軟件開發(fā)方法的解決方案。 一、 項目與公司背景 該項目是一個PRM (Partner Relationship Management)系統(tǒng)，為世界著名的快速消費(fèi)品品牌在中國大陸的合作伙伴提供訂單管理以及其它輔助功能。該系統(tǒng)原來是基于PHP實(shí)現(xiàn)的，已經(jīng)運(yùn)行將近2年的時間，但是由于系統(tǒng)功能問題，需要對系統(tǒng)進(jìn)行重新開發(fā)，新的系統(tǒng)基于J2EE框架實(shí)現(xiàn)。 項目預(yù)期情況如下： 項目開始時間： 2002年7月1日 預(yù)期交付時間： 2002年9月1日 項目金額： 70萬RMB 項目開發(fā)商是亞洲領(lǐng)先的電子商務(wù)解決方案供應(yīng)商，在J2EE架構(gòu)的項目執(zhí)行方面有豐富的經(jīng)驗(yàn)，結(jié)合RUP與Web Software Engineering形成了自己的一套電子商務(wù)項目實(shí)施方法論，并在多個項目中成功進(jìn)行實(shí)施。 二、 項目實(shí)施情況 項目由于客戶預(yù)算等原因，原有的軟、硬件系統(tǒng)繼續(xù)使用，同時，應(yīng)用系統(tǒng)平臺也采用開源項目。 項目部署時的系統(tǒng)情況如下： 硬件： 操作系統(tǒng)： Solaris 主頻： 400M 內(nèi)存： 1G 硬盤： 20G 應(yīng)用平臺： Web服務(wù)器： Apache 1.3.21 應(yīng)用服務(wù)器： Tomcat 4.0.6 數(shù)據(jù)庫服務(wù)器： Oracle 8.1.7 項目人員配置與項目規(guī)模： 項目團(tuán)隊 項目經(jīng)理： 1 技術(shù)經(jīng)理： 1（兼） 客戶經(jīng)理： 1 開發(fā)人員： 4 測試人員： 2 HTML人員： 1（兼） 項目規(guī)模 Use Case： 32 代碼行數(shù)： 65000 JSP頁面： 198 項目真實(shí)執(zhí)行情況： 開始日期： 2002/7/1 交付日期： 2002/9/2 驗(yàn)收日期： 2003/5/8 維護(hù)時間： 230 人小時 目前項目盈利： 20000 目前，項目由于性能問題，仍然沒有驗(yàn)收，維護(hù)時間日益增長，目前仍然有30萬左右的尾款沒有收到；更為嚴(yán)重的是，目前項目開發(fā)商正在投標(biāo)的另一快速消費(fèi)品行業(yè)著名客戶的合作伙伴與該客戶有很大的重疊，因此，對于潛在項目的招標(biāo)造成一定的影響。 三、 經(jīng)驗(yàn)與教訓(xùn) 從項目規(guī)模中可以看出，該項目的時間還是比較緊張的；另外一方面，項目交付是在合同規(guī)定日期之前完成，而且通過了所有的功能測試。從一定意義上的講，項目的開發(fā)是取得了一定的成功的。 3.1 經(jīng)驗(yàn) 在項目開發(fā)前，項目開發(fā)商已經(jīng)通過其它項目，實(shí)施了以XP為代表的敏捷軟件開發(fā)方法的部分最佳實(shí)踐，并取得了很大的成功。因此，在該項目的執(zhí)行過程中，項目開發(fā)商繼續(xù)采用了XP的部分實(shí)踐以及其它軟件開發(fā)方法中的推薦做法[1][2]： 每日晨會：在項目實(shí)施過程中，每天早晨開發(fā)小組都要參加一個持續(xù)15分鐘左右的會議，由項目經(jīng)理主持，聽取每個成員的進(jìn)度，并根據(jù)進(jìn)展情況，對于進(jìn)度和資源進(jìn)行調(diào)整。 由于會議是每天進(jìn)行的，PM很容易從中獲得真實(shí)的項目情況－"掀開地毯下面的東西"[4]，從而對風(fēng)險有了較好的控制。 交叉審核：項目組在最初的時候原本是想采取"成對編程"的實(shí)踐，但是沒有獲得物理和管理上的支持，因此，只能采取交叉審核的方式進(jìn)行。 需求獲取：由PM和一名對于原有系統(tǒng)較熟悉的開發(fā)人員進(jìn)行需求獲取和SRS (Software Requirement Specification) 的撰寫。技術(shù)經(jīng)理和其它開發(fā)人員進(jìn)行需求的審核。 分析與設(shè)計：由一名開發(fā)人員進(jìn)行系統(tǒng)框架的設(shè)計，其它人員進(jìn)行審核；在系統(tǒng)框架設(shè)計進(jìn)行過程中，由于系統(tǒng)去除訂單處理以外的其它部分比較獨(dú)立，因此，將其它模塊分配給開發(fā)人員，而將核心部分交與技術(shù)經(jīng)理進(jìn)行分析與設(shè)計。開發(fā)人員在每個迭代周期內(nèi)，都會在分析與設(shè)計做完后，每2人一組進(jìn)行審核。 編碼：每天下班前，2人一組，對對方的代碼進(jìn)行Review，發(fā)現(xiàn)問題及時解決。代碼Review的時候，語法與規(guī)則的檢查，通過Check Style的工具進(jìn)行；開發(fā)人員將審查的重點(diǎn)放在功能實(shí)現(xiàn)與性能優(yōu)化等方面。 測試：在需求文檔形成以后，2個測試人員分布編寫分配模塊的Test Case；而在具體測試的時候，兩人交叉測試對方的模塊和更新文檔。 在系統(tǒng)開發(fā)Verification的各個階段，都有Check List，詳細(xì)的信息請查看參考文獻(xiàn)[3]。 測試先行：測試在軟件開發(fā)中的重要作用已經(jīng)得到了越來越多的重視，但是，由于習(xí)慣勢力的影響和對于"Test-Driven Development"的不熟悉，開發(fā)小組并沒有實(shí)施完全意義上的測試先行。 對于系統(tǒng)框架的核心類設(shè)計過程中，項目小組采取了TDD的方式進(jìn)行開發(fā)。在后續(xù)的系統(tǒng)開發(fā)中，每個開發(fā)人員在進(jìn)行開發(fā)前，首先要完成一個功能測試 ( Function Test ) 列表，將要完成的Use Case中的主要業(yè)務(wù)邏輯以及關(guān)聯(lián)邏輯都要羅列出來，在提交測試人員進(jìn)行集成測試之前，開發(fā)人員需要保證完成Function List中的所有選項。 在每個開發(fā)人員的模塊完成并通過個人的功能測試后，測試人員進(jìn)行集成測試，同時編寫測試腳本，并通過自動測試工具 (Rational Robot) 進(jìn)行記錄。每天下班之前，測試人員會啟動測試工具，進(jìn)行回歸測試。在第二天向PM和技術(shù)經(jīng)理提交測試報告并將Bug提交至Bug Trace系統(tǒng)（Rational Clear Quest），由PM進(jìn)行Bug的分發(fā)。每個開發(fā)人員需要在下一個迭代周期完成前，修正前一個迭代內(nèi)分配的Bug。 持續(xù)集成：在測試先行的基礎(chǔ)上，開發(fā)一組平均每天都會進(jìn)行已經(jīng)完成模塊與以后系統(tǒng)的集成。集成由專門的人員，在開發(fā)人員將已經(jīng)通過功能測試的源碼Check in到源碼控制系統(tǒng) (ClearCase) 中以后進(jìn)行，在部署應(yīng)用結(jié)束以后，通知測試人員進(jìn)行集成測試。 小步發(fā)布：項目有專門的測試與發(fā)布服務(wù)器，每天都有集成的系統(tǒng)在運(yùn)行和接受測試。由于沒有現(xiàn)場客戶，對于已經(jīng)發(fā)布的系統(tǒng)，是由"客戶領(lǐng)域?qū)＜?（這個項目是由Business Development人員來充當(dāng)這個角色）來進(jìn)行審查的。他對于系統(tǒng)的意見和發(fā)現(xiàn)的問題，在經(jīng)過PM和技術(shù)經(jīng)理審核后，進(jìn)入ClearQuest，分配給開發(fā)人員進(jìn)行修改。 由于項目一開始就注意組織內(nèi)部以及與客戶的溝通和交流，同時采用了很多敏捷軟件開發(fā)過程的實(shí)踐，項目如期交付使用。 3.2 教訓(xùn) 項目在交付以后，最初的兩個訂貨季節(jié)沒有出現(xiàn)功能與性能上的問題。但是，由于合同中有數(shù)據(jù)遷移的條款，在項目交付2月后，項目開發(fā)商將舊應(yīng)用系統(tǒng)中的數(shù)據(jù)導(dǎo)入新系統(tǒng)以后，在下一個大的訂貨季節(jié)中，持續(xù)的出現(xiàn)性能上的問題。在代碼修改和硬件環(huán)境提高以后，系統(tǒng)性能目前獲得了一定的改善。 從項目驗(yàn)收日期的日益推遲中，我們可以看出，該項目還是有很多地方做的不夠，例如： 系統(tǒng)二次開發(fā)效應(yīng)："第二個系統(tǒng)效應(yīng)"是Brooks在《人月神話》中提出的一個普遍的問題，一般而言，第二個系統(tǒng)會傾向于過分設(shè)計[4]。 對于這個項目而言，沒有犯這個錯誤，卻發(fā)生了另外一種情況：舊系統(tǒng)中，對于訂單信息以及產(chǎn)品信息的展示，不管是多是少（系統(tǒng)頁面最多顯示上千條記錄），都是在一個頁面中顯示。這對于沒有明顯的層次結(jié)構(gòu)，直接在Script中調(diào)用數(shù)據(jù)庫記錄的PHP來說，性能還是可以接受的。但是，新系統(tǒng)的設(shè)計中客戶提出考慮系統(tǒng)用戶習(xí)慣一致性的問題，就照搬了舊系統(tǒng)的頁面設(shè)計；同時，在架構(gòu)設(shè)計上，對于這種頁面顯示大量數(shù)據(jù)的情況，也沒有給予充分的考慮，為后來的性能問題，埋下了伏筆。 教訓(xùn)一：沒有考慮新平臺的影響，照搬舊系統(tǒng)的功能以及頁面設(shè)計。 非功能性需求：項目合同中主要描述的是系統(tǒng)功能性的需求，而沒有非功能性需求的規(guī)定；同時，在需求獲取解決，也沒有明確的了解系統(tǒng)的性能指標(biāo)等非功能性需求。主要原因在于項目開發(fā)商之前沒有大規(guī)模業(yè)務(wù)系統(tǒng)開發(fā)的經(jīng)驗(yàn)，對于非功能性需求沒有足夠的重視；同時，在測試階段，也沒有對于系統(tǒng)負(fù)載和性能做過測試。 因此，在項目交付以后，由于舊系統(tǒng)數(shù)據(jù)遷移后，數(shù)據(jù)量有了很大的增長，同時，在秋季的定購高峰中，有大量的并發(fā)用戶訪問，出現(xiàn)了下列問題： 數(shù)據(jù)庫死鎖； 大量數(shù)據(jù)計算與顯示頁面速度很慢，頁面要經(jīng)過5～10分鐘才能夠完全顯示； 上述兩種情況在少量負(fù)載的單元測試和集成測試中是不可能出現(xiàn)的。 教訓(xùn)二：對于企業(yè)應(yīng)用系統(tǒng)，尤其是業(yè)務(wù)系統(tǒng)，沒有切實(shí)注意負(fù)載、性能等非功能性需求。 效率與設(shè)計：在J2EE中，已經(jīng)成功的運(yùn)用了很多設(shè)計模式的思想，為系統(tǒng)的開發(fā)提供了一個很好框架。但是，在項目的架構(gòu)設(shè)計中，除了考慮可維護(hù)性、可復(fù)用性等問題以外，還要考慮代碼執(zhí)行效率的問題[5]。 隨著計算機(jī)硬件技術(shù)的發(fā)展，"莫爾定律"被一再的驗(yàn)證，系統(tǒng)硬件的價格逐漸降低。對于很多使用J2EE架構(gòu)或者JAVA技術(shù)的項目來說，解決性能與效率問題的解決方案就是增加硬件方面的投入。而實(shí)際上，軟件開發(fā)過程中優(yōu)劣算法之間的差距是靠硬件的投入平衡不了的。 該項目在系統(tǒng)維護(hù)期間，對代碼進(jìn)行走查，修改了很多對于性能有影響的語句；同時，在框架設(shè)計中，尤其是數(shù)據(jù)庫操作方法，利用Cache原理，從一定程度上解決了性能的問題。 教訓(xùn)三：系統(tǒng)框架設(shè)計只考慮面向?qū)ο蠛涂删S護(hù)性，沒有在完美的設(shè)計與高效率的代碼之間做出權(quán)衡。 數(shù)據(jù)庫設(shè)計：JAVA是純粹的面向?qū)ο笳Z言，利用J2EE開發(fā)的項目，也強(qiáng)調(diào)首先進(jìn)行OOAD的分析，首先有對象，然后再有數(shù)據(jù)庫的設(shè)計。DBA在項目中的作用，已經(jīng)遠(yuǎn)遠(yuǎn)沒有傳統(tǒng)的結(jié)構(gòu)性編程中重要。而實(shí)際情況卻是遠(yuǎn)非如此：大部分的業(yè)務(wù)系統(tǒng)，如果要對系統(tǒng)的性能做出優(yōu)化，對數(shù)據(jù)庫層或者SQL語句進(jìn)行優(yōu)化是關(guān)鍵的步驟之一。 對于這個PRM系統(tǒng)，在數(shù)據(jù)庫的設(shè)計上并沒有經(jīng)過DBA的審查就開始進(jìn)行開發(fā)；而在性能問題出現(xiàn)以后，客戶增加了512M的內(nèi)存，也沒有請求DBA對Oracle的參數(shù)做相應(yīng)的調(diào)整，造成了很大的資源浪費(fèi)。 在項目維護(hù)過程中，依靠DBA的幫助，開發(fā)商對于數(shù)據(jù)庫系統(tǒng)參數(shù)、索引、存儲過程和SQL語句都做了一定的調(diào)整，這對于系統(tǒng)性能的提高起了很大的作用。 教訓(xùn)四：在面向?qū)ο蟮能浖到y(tǒng)構(gòu)建中，忽視數(shù)據(jù)庫設(shè)計以及DBA的重要作用。 客戶參與：在傳統(tǒng)的軟件開發(fā)過程中，一般情況下，客戶在簽訂合同后，項目交付前是很少有機(jī)會看到系統(tǒng)的，這樣就造成了系統(tǒng)交付后，客戶抱怨很多的情況；而在以XP為代表的敏捷軟件開發(fā)方法中，強(qiáng)化了客戶在軟件開發(fā)中的重要作用，XP更是提出了"現(xiàn)場客戶"的實(shí)踐，將客戶作為項目小組的一員，客戶對于項目的發(fā)布計劃、內(nèi)容和優(yōu)先級等方面有絕對的控制權(quán)。 對于這個PRM項目，由于客戶的原因，不可能采取"現(xiàn)場客戶"的實(shí)踐，但是，開發(fā)商的BD對于該客戶十分熟悉，完全可以作為客戶代表參與到項目中來，因此，開發(fā)商將客戶經(jīng)理作為項目組的一員。 實(shí)際情況是：開發(fā)過程中，客戶經(jīng)理由于業(yè)務(wù)拓展的原因，并沒有在項目上分配多少時間進(jìn)行審查；而客戶在交付前也沒有花費(fèi)很多的時間研究系統(tǒng)，也沒有提交很多的反饋報告。在系統(tǒng)交付出現(xiàn)性能等問題后，客戶經(jīng)理與開發(fā)人員一起對于系統(tǒng)需求進(jìn)行審查，提出了很多有參考性的意見。如果從一開始，就強(qiáng)化"現(xiàn)場客戶"的最佳實(shí)踐，就可以很早發(fā)現(xiàn)問題。 教訓(xùn)五：客戶或者客戶經(jīng)理對于項目的參與力度不夠。 四、 結(jié)論 在基于J2EE的企業(yè)應(yīng)用項目開發(fā)中，要注意以下問題： 權(quán)衡系統(tǒng)設(shè)計與性能指標(biāo)，關(guān)注非功能性需求； 采取敏捷軟件開發(fā)過程，關(guān)注人（客戶和開發(fā)人員）在項目實(shí)施中的重要作用，如果可以的話，聯(lián)合實(shí)施XP的所有實(shí)踐； 五、 參考文獻(xiàn) [1] Agile Software Development Alistair Cockburn [2] Extreme Programming Explained - Embrace Change Kent Beck [3] Software Verification and Validation for Practitioners and Managers Steven R. Rakitin [4] The Mythical Man-Month Frederick P. Brooks Jr. [5] Expert One-To-One J2EE Design and Development Rod Johnson 作者簡介： 曲俊生，某咨詢公司資深顧問。有近5年的軟件開發(fā)經(jīng)驗(yàn)和2年的項目管理實(shí)踐。目前他的研究與開發(fā)興趣在J2EE, XP, TDD 以及Design Pattern。目前居住在上海，喜歡爬山、旅游等休閑活動，你可以通過junshengqu@yahoo.com.cn與他聯(lián)系。 |
|站長郵箱|小黑屋|手機(jī)版|Office中國/Access中國
( 粵ICP備10043721號-1 )
GMT+8, 2025-7-13 08:46 , Processed in 0.188322 second(s), 16 queries .
Powered by Discuz! X3.3
© 2001-2017 Comsenz Inc.
