擴展性。雖然這為系統(tǒng)的后期維護帶來一定隱患，但卻能夠有效地保證項目的進度。從EAS最初的架構設計來看，我們引入了Ca stle與AOP，試圖簡化ORM以及橫切關注點例如日志、異常、權限、事務等功能的實現(xiàn)。同時，希望采用WCF，利用SOA思想建立松散耦合的面向服務應用程序。但隨著客戶需求的變化，我們果斷地放棄了采用WCF的構想，同時又克服了技術困難，堅持了對Ca stle與AOP的使用，并為此成立了框架開發(fā)小組。事實證明，在技術的抉擇上我們作出了正確的決定。
重視UI原型設計。系統(tǒng)的原型設計與需求分析相輔相成。如果有好的原型版本交付給客戶，則客戶更能夠理解系統(tǒng)的實現(xiàn)，促進溝通的有效性與準確性。在EAS項目中，我們從一開始就確立了原型設計小組，并在分析需求階段，就開始了原型設計。這一做法無疑在客戶溝通、需求確認、UI設計等方面都發(fā)揮了很大的作用。但是，我們在這一點上，由于缺乏專門的UI設計人員，因此，這一工作還存在很大的缺陷，甚至于UI的設計為迭代版本的交付帶來了很大的障礙。在項目后期，關于UI的bug是最多。因此，我們認為在開發(fā)類似的WEB應用程序時，應盡早確立UI設計規(guī)范，以約束所有的UI設計。同時，必須培養(yǎng)專門的UI設計師，在開始原型設計時，就盡快完成UI交互的設計。并且，必須成立專門的UI設計小組，在需求階段與需求分析師合作，在編碼階段與開發(fā)人員合作。
軟件測試
軟件測試成員應了解需求。如果不了解需求，測試人員無法編寫正確的測試用例，同時在測試過程中，也可能因為錯誤地理解需求，從而導致報告錯誤的bug，影響開發(fā)人員效率。
加強開發(fā)人員與測試人員的合作。開發(fā)人員必須及時響應測試人員提交的bug。而測試人員也應跟蹤開發(fā)人員對bug的修復情況。
測試之初必須確定測試原則，對bug的嚴重程度進行分級。同時，必須確定修復bug的優(yōu)先級別。
項目管理方面
進度管理
保證項目進度不出現(xiàn)大的偏差的前提是制定一個好的項目計劃。必須根據(jù)項目規(guī)模，成員情況，技術難度等多方面考慮整個項目計劃。如果項目的deadline已經(jīng)確定，則必須采用一些方法來保障項目計劃的完成。首先是選擇符合項目的軟件開發(fā)生命周期。通常情況下，并不建議采用瀑布開發(fā)方式。最佳的辦法，應該是RUP或者敏捷開發(fā)，然后結(jié)合原型法制訂項目計劃。這樣可以規(guī)避因為需求變更產(chǎn)生的風險。
其次，要每日跟蹤項目的進展情況。可以通過晨會、周會以及項目日報、項目周報了解項目進展情況。同時，需要為各個小組指定進度跟蹤人，根據(jù)各個小組長的日報，判斷實際的進度是否與計劃出現(xiàn)偏差。
要制定項目進度偏差的應對方法。一旦項目進度出現(xiàn)了偏差，必須采取相應錯誤解決問題?；蛘咄ㄟ^加班、增加人手、申請項目進度等方法及時作出響應。
及時向項目成員匯報項目進度情況。只有讓各個項目成員了解到項目現(xiàn)狀，才能夠給每個成員增加壓力，不至于松懈。同時，也能夠使得每個成員能有一個目標，而不至于茫然失措。
制定項目計劃時，必須考慮階段評審與同行評審的時間。這一點在EAS項目中做得不夠好。其中原因也是由于項目進度本身較緊的緣故。
注意維護項目進度跟蹤表與項目進度偏差跟蹤表。讓項目管理部以及QA及時掌握項目進度，有利于對項目進度的管理。
變更管理
變更包括需求變更、人員變更。如果不控制好，兩者對項目的進展都會帶來災難性的后果。需求變更在前面已經(jīng)敘述，而EAS項目中發(fā)現(xiàn)人員變更的情況也非常嚴重，因此這里重點介紹關于人員變更