軟件項目投標(biāo)技術(shù)方案

本頁僅作為文檔頁封面，使用時可以刪除

Thisdocumentisforreferenceonly-rar21year.March本頁僅作為文檔頁封面，使用時可以刪除

Thisdocumentisforreferenceonly-rar21year.March軟件項目投標(biāo)技術(shù)方案PAGE目錄1. 技術(shù)服務(wù)總體要求 12. 項目總體架構(gòu)及技術(shù)解決方案 5. 項目總體架構(gòu)（根據(jù)實際項目） 5 SSH框架介紹和分析 5 基于SSH框架的Web應(yīng)用架構(gòu)分析與設(shè)計 9. 技術(shù)解決方案 123. 服務(wù)保證措施 264. 技術(shù)培訓(xùn)計劃 30. 概述 30. 培訓(xùn)對象 31 普通用戶層 31 系統(tǒng)管理員和應(yīng)用級管理員 31 技術(shù)人員培訓(xùn) 31. 培訓(xùn)課程 32 應(yīng)用系統(tǒng)使用培訓(xùn) 32 系統(tǒng)運維技術(shù)培訓(xùn) 32 項目管理初級（可選） 32 系統(tǒng)支撐軟、硬件環(huán)境應(yīng)用管理 32 系統(tǒng)設(shè)計與開發(fā)基礎(chǔ)（可選） 33. 培訓(xùn)組織保障 33. 教學(xué)方案 33 實踐培訓(xùn) 34 集中培訓(xùn) 34 研討會 34 遠程培訓(xùn) 35 一對一培訓(xùn) 35. 培訓(xùn)規(guī)模設(shè)定建議 35. 培訓(xùn)階段安排 35 系統(tǒng)開發(fā)階段 36 初驗 36 系統(tǒng)安裝 36 調(diào)試 36 試運行 36 最終驗收 37. 培訓(xùn)質(zhì)量保障 375. 售后服務(wù)方案 37. 安裝調(diào)試服務(wù) 38. 售后電話服務(wù) 38. 上門服務(wù) 38技術(shù)服務(wù)總體要求在軟件開發(fā)的過程中，我們一向遵循軟件產(chǎn)品的以下原則：1、功能性:與一組功能及其指定的性質(zhì)有關(guān)的一組屬性，具體包括：適合性:與規(guī)定任務(wù)能否提供一組功能以及這組功能的適合程度有關(guān)的軟件屬性準確性:與能否得到正確或相符的結(jié)果或效果有關(guān)的軟件屬性互用性:與同其他指定系統(tǒng)進行交互的能力有關(guān)的軟件屬性依從性:使軟件遵循有關(guān)的標(biāo)準,約定,法規(guī)及類似規(guī)定的軟件屬性安全性:與防止對程序及數(shù)據(jù)的非授權(quán)的故意或意外訪問的能力有關(guān)的軟件屬性2、可靠性:與在規(guī)定的一段時間和條件下,軟件維持其性能水平的能力有關(guān)的一組屬性，具體包括：成熟性:與由軟件故障引起失效的頻度有關(guān)的軟件屬性容錯性:與在軟件故障或違反指定接口的情況下,維持規(guī)定的性能水平的能力有關(guān)的軟件屬性易恢復(fù)性:與在失效發(fā)生后,重建其性能水平并恢復(fù)直接受影響數(shù)據(jù)的能力以及為達此目的所需的時間和能力有關(guān)的軟件屬性3、易用性:與一組規(guī)定或潛在的用戶為使用軟件所需作的努力和對這樣的使用所作的評價有關(guān)的一組屬性，具體包括：易理解性:與用戶為認識邏輯概念及其應(yīng)用范圍所花的努力有關(guān)的軟件屬性易學(xué)性:與用戶為學(xué)習(xí)軟件應(yīng)用所花的努力有關(guān)的軟件屬性易操作性:與用戶為操作和運行控制所花努力有關(guān)的軟件屬性4、效率:與在規(guī)定的條件下,軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性，具體包括：時間特性:與軟件執(zhí)行其功能時響應(yīng)和處理時間以及吞吐量有關(guān)的軟件屬性資源特性:與在軟件執(zhí)行其功能時所使用的資源數(shù)量及其使用時間有關(guān)的軟件屬性5、可維護性:與進行指定的修改所需的努力有關(guān)的一組屬性，具體包括：易分析性:與為診斷缺陷或失效原因及為判定待修改的部分所需努力有關(guān)的軟件屬性易改變性:與進行修改,排除錯誤或適應(yīng)環(huán)境變化所需努力有關(guān)的軟件屬性穩(wěn)定性:與修改所造成的未預(yù)料結(jié)果的風(fēng)險有關(guān)的軟件屬性易測試性:與確認已修改軟件所需的努力有關(guān)的軟件屬性6、可移植性:與軟件可從某一環(huán)境轉(zhuǎn)移到另一環(huán)境的能力有關(guān)的一組屬性，具體包括：適應(yīng)性:與軟件無需采用有別于為該軟件準備的活動或手段就可能適應(yīng)不同的規(guī)定環(huán)境有關(guān)的軟件屬性易安裝性:與在指定環(huán)境下安裝軟件所需努力有關(guān)的軟件屬性遵循性:使軟件遵循與可移植性有關(guān)的標(biāo)準或約定的軟件屬性易替換性:與軟件在該軟件環(huán)境中用來替代指定的其他軟件的機會和努力有關(guān)的軟件屬性基于以上原則，根據(jù)項目的不同需求，我們將會考慮采用B/S和C/S兩種模式開發(fā)。（根據(jù)實際項目來）1、B/S模式B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如NetscapeNavigator或InternetExplorer，服務(wù)器安裝Oracle、Sybase、Informix或SQLServer等數(shù)據(jù)庫。瀏覽器通過WebServer同數(shù)據(jù)庫進行數(shù)據(jù)交互。B/S模式較C/S模式： C/S模式客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部的情況，不是工作量的問題，而是路程的問題。還有，系統(tǒng)軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。C/S模式對客戶端的操作系統(tǒng)一般也會有限制，可能適應(yīng)于Windows系列操作系統(tǒng)，而不適用于Linux、Unix等操作系統(tǒng)。而B/S最大的優(yōu)點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網(wǎng)的電腦就能使用，客戶端零維護。系統(tǒng)的擴展非常容易，只要能上網(wǎng)，再由系統(tǒng)管理員分配一個用戶名和密碼，就可以使用了。甚至可以在線申請，通過公司內(nèi)部的安全認證（如CA證書）后，不需要人的參與，系統(tǒng)可以自動分配給用戶一個賬號進入系統(tǒng)，這在最大程度上滿足了項目要求。系統(tǒng)采用的是目前較流行的一種Web應(yīng)用程序開源框架--Struts+Spring+Hibernate（SSH）。集成SSH框架的系統(tǒng)從職責(zé)上分為四層：表示層、業(yè)務(wù)邏輯層、數(shù)據(jù)持久層和域模塊層，以幫助開發(fā)人員在短期內(nèi)搭建結(jié)構(gòu)清晰、可復(fù)用性好、維護方便的Web應(yīng)用程序。其中使用Struts作為系統(tǒng)的整體基礎(chǔ)架構(gòu)，負責(zé)MVC的分離，在Struts框架的模型部分，利用Hibernate框架對持久層提供支持，業(yè)務(wù)層用Spring支持。具體做法是：用面向?qū)ο蟮姆治龇椒ǜ鶕?jù)需求提出一些模型，將這些模型實現(xiàn)為基本的Java對象，然后編寫基本的DAO接口，并給出Hibernate的DAO實現(xiàn)，采用Hibernate架構(gòu)實現(xiàn)的DAO類來實現(xiàn)Java類與數(shù)據(jù)庫之間的轉(zhuǎn)換和訪問，最后由Spring完成業(yè)務(wù)邏輯。系統(tǒng)的基本業(yè)務(wù)流程是：在表示層中，首先通過JSP頁面實現(xiàn)交互界面，負責(zé)傳送請求(Request)和接收響應(yīng)(Response)，然后Struts根據(jù)配置文件將ActionServlet接收到的Request委派給相應(yīng)的Action處理。在業(yè)務(wù)層中，管理服務(wù)組件的SpringIoC容器負責(zé)向Action提供業(yè)務(wù)模型(Model)組件和該組件的協(xié)作對象數(shù)據(jù)處理(DAO)組件完成業(yè)務(wù)邏輯，并提供事務(wù)處理、緩沖池等容器組件以提升系統(tǒng)性能和保證數(shù)據(jù)的完整性。而在持久層中，則依賴于Hibernate的對象化映射和數(shù)據(jù)庫交互，處理DAO組件請求的數(shù)據(jù)，并返回處理結(jié)果。采用上述開發(fā)模型，不僅實現(xiàn)了視圖、控制器與模型的徹底分離，而且還實現(xiàn)了業(yè)務(wù)邏輯層與持久層的分離。這樣無論前端如何變化，模型層只需很少的改動，并且數(shù)據(jù)庫的變化也不會對前端有所影響，大大提高了系統(tǒng)的可復(fù)用性。而且由于不同層之間耦合度小，有利于團隊成員并行工作，大大提高了開發(fā)效率的同時，也保證了軟件產(chǎn)品的質(zhì)量。2、C/S模式C/S（Client/Server，客戶機/服務(wù)器）模式又稱C/S結(jié)構(gòu)，是20世紀80年代末逐步成長起來的一種模式，是軟件系統(tǒng)體系結(jié)構(gòu)的一種。C/S結(jié)構(gòu)的關(guān)鍵在于功能的分布，一些功能放在前端機（即客戶機）上執(zhí)行，另一些功能放在后端機（即服務(wù)器）上執(zhí)行。功能的分布在于減少計算機系統(tǒng)的各種瓶頸問題。C/S模式簡單地講就是基于企業(yè)內(nèi)部網(wǎng)絡(luò)的應(yīng)用系統(tǒng)。與B/S（Browser/Server，瀏覽器/服務(wù)器）模式相比，C/S模式的應(yīng)用系統(tǒng)最大的好處是不依賴企業(yè)外網(wǎng)環(huán)境，即無論企業(yè)是否能夠上網(wǎng)，都不影響應(yīng)用。C/S結(jié)構(gòu)服務(wù)器通常采用高性能的PC、工作站或小型機，并采用大型數(shù)據(jù)庫系統(tǒng)，如ORACLE、SYBASE、InfORMix或SQLServer。客戶端需要安裝專用的客戶端軟件。C/S結(jié)構(gòu)的優(yōu)點是能充分發(fā)揮客戶端PC的處理能力，很多工作可以在客戶端處理后再提交給服務(wù)器,因此對應(yīng)的優(yōu)點就是客戶端響應(yīng)速度快。C/S架構(gòu)軟件的優(yōu)勢與劣勢：（1）應(yīng)用服務(wù)器運行數(shù)據(jù)負荷較輕。最簡單的C/S體系結(jié)構(gòu)的數(shù)據(jù)庫應(yīng)用由兩部分組成，即客戶應(yīng)用程序和數(shù)據(jù)庫服務(wù)器程序。二者可分別稱為前臺程序與后臺程序。運行數(shù)據(jù)庫服務(wù)器程序的機器，也稱為應(yīng)用服務(wù)器。一旦服務(wù)器程序被啟動，就隨時等待響應(yīng)客戶程序發(fā)來的請求；客戶應(yīng)用程序運行在用戶自己的電腦上，對應(yīng)于數(shù)據(jù)庫服務(wù)器，可稱為客戶電腦，當(dāng)需要對數(shù)據(jù)庫中的數(shù)據(jù)進行任何操作時，客戶程序就自動地尋找服務(wù)器程序，并向其發(fā)出請求，服務(wù)器程序根據(jù)預(yù)定的規(guī)則作出應(yīng)答，送回結(jié)果，應(yīng)用服務(wù)器運行數(shù)據(jù)負荷較輕。（2）數(shù)據(jù)的儲存管理功能較為透明。在數(shù)據(jù)庫應(yīng)用中，數(shù)據(jù)的儲存管理功能，是由服務(wù)器程序和客戶應(yīng)用程序分別獨立進行的，并且通常把那些不同的（不管是已知還是未知的）前臺應(yīng)用所不能違反的規(guī)則，在服務(wù)器程序中集中實現(xiàn)，例如訪問者的權(quán)限，編號可以重復(fù)、必須有客戶才能建立定單這樣的規(guī)則。所有這些，對于工作在前臺程序上的最終用戶，是“透明”的，他們無須過問（通常也無法干涉）背后的過程，就可以完成自己的一切工作。在客戶服務(wù)器架構(gòu)的應(yīng)用中，前臺程序不是非?！笆菪　?，麻煩的事情都交給了服務(wù)器和網(wǎng)絡(luò)。在C/S體系的下，數(shù)據(jù)庫不能真正成為公共、專業(yè)化的倉庫，它受到獨立的專門管理。C/S模式系統(tǒng)的開發(fā)：C/S結(jié)構(gòu)是建立在中間件產(chǎn)品基礎(chǔ)之上的，要求應(yīng)用開發(fā)者自己去處理事務(wù)管理、消息隊列、數(shù)據(jù)的復(fù)制和同步、通信安全等系統(tǒng)級的問題。這對應(yīng)用開發(fā)者提出了較高的要求，而且迫使應(yīng)用開發(fā)者投入很多精力來解決應(yīng)用程序以外的問題。這使得應(yīng)用程序的維護、移植和互操作變得復(fù)雜。如果客戶端是在不同的操作系統(tǒng)上，C/S結(jié)構(gòu)的軟件需要開發(fā)不同版本的客戶端軟件。但是，與B/S結(jié)構(gòu)相比，C/S技術(shù)發(fā)展歷史更為“悠久”。從技術(shù)成熟度及軟件設(shè)計、開發(fā)人員的掌握水平來看，C/S技術(shù)應(yīng)是更成熟、更可靠的。項目總體架構(gòu)及技術(shù)解決方案項目總體架構(gòu)（根據(jù)實際項目）SSH框架介紹和分析大型企業(yè)級Web應(yīng)用系統(tǒng)的開發(fā)通常要求有一個良好的軟件架構(gòu)、便于協(xié)作開發(fā)和擴展升級，而傳統(tǒng)的開發(fā)模式不能很好地滿足這些要求?；诋?dāng)前Web應(yīng)用程序開發(fā)面臨的問題，項目結(jié)合目前比較流行的開源框架SSH（Spring、Struts、Hibernate)，具體討論其基本相似性及有關(guān)基本概念，提出了一種開發(fā)JavaEEWeb應(yīng)用的輕量級解決方案，此系統(tǒng)架構(gòu)可以在短期內(nèi)搭建結(jié)構(gòu)清晰、可復(fù)用性好、可擴展性好、維護方便的Web應(yīng)用程序。1、框架技術(shù)框架一般具有即插即用的可重用性、成熟的穩(wěn)定性以及良好的團隊協(xié)作性。JavaEE復(fù)雜的多層結(jié)構(gòu)決定了大型的JavaEE項目需要運用框架和設(shè)計模式來控制軟件質(zhì)量。目前，市場上出現(xiàn)了一些商業(yè)的、開源的基于JavaEE的應(yīng)用框架，其中主流的框架技術(shù)有：基于MVC模式的Struts框架、基于IoC模式的Spring框架以及對象/關(guān)系映射框架Hibernate等。2、框架共同點所有現(xiàn)代的網(wǎng)絡(luò)開發(fā)框架幾乎都遵循了模型-視圖-控制(MVC)設(shè)計模式：商業(yè)邏輯和描述被分開，由一個邏輯流控制器來協(xié)調(diào)來自客戶端的請求和服務(wù)器上將采取的行動。這條途徑成為了網(wǎng)絡(luò)開發(fā)的事實上的標(biāo)準。每個框架的內(nèi)在的機制當(dāng)然是不同的，但是開發(fā)者們使用來設(shè)計和實現(xiàn)他們的Web應(yīng)用軟件的API是很類似的。差別還存在于每個框架提供的擴展方面,例如標(biāo)簽庫，JavaBean包裝器等。所有的框架使用不同的技術(shù)來協(xié)調(diào)在Web應(yīng)用程序之內(nèi)的導(dǎo)航,例如XML配制文件，java屬性文件或定制屬性。所有的框架在控制器模塊實現(xiàn)的方法方面也存在明顯的不同。例如,EJB可能實例化在每個請求中需要的類或使用Java反射動態(tài)地調(diào)用一個適當(dāng)?shù)男袨椋ˋction）類。另外,不同框架在各自引入的概念上也有所不同。例如,一個框架可能定義用戶請求和反應(yīng)場所，而另外一個框架可能僅僅定義一個完整的流：從一個請求到多個響答和隨后的再請求。各種Java框架在它們組織數(shù)據(jù)流的方法方面是很類似的。在請求發(fā)出后，在應(yīng)用程序服務(wù)器上產(chǎn)生一些行動；而作為響應(yīng)，一些可能包含對象集的數(shù)據(jù)總是被發(fā)送到WEB層。然后從那些對象：可能是有setter和getter方法的簡單類、JAVABEANS、值對象、或者一些集合對象中提取數(shù)據(jù)。現(xiàn)代的Java框架還想方設(shè)法簡化開發(fā)者的開發(fā)任務(wù)，如通過使用簡易的API、數(shù)據(jù)庫連接池、甚至數(shù)據(jù)庫調(diào)用包等提供自動化的追蹤方式來實現(xiàn)。一些框架或者能夠鉤進（hookedinto）另外的JavaEE技術(shù)中,例如JMS(Java消息服務(wù))或JMX,或把這些技術(shù)集成到一起。服務(wù)器數(shù)據(jù)持續(xù)性和日志也有可能成為框架的一部分。3、MVC模式MVC模式是一個用于將用戶界面邏輯與業(yè)務(wù)邏輯分離開來的基礎(chǔ)設(shè)計模式，它將數(shù)據(jù)處理、界面以及用戶的行為控制分為：Model（模型）－View（視圖）－Controller（控制器）。Model：負責(zé)當(dāng)前應(yīng)用的數(shù)據(jù)獲取與變更及相關(guān)的業(yè)務(wù)邏輯。可用JAVABEAN來體現(xiàn)；View：負責(zé)顯示信息?？梢允褂肑SP、VELOCITY模板等技術(shù)；Controller：負責(zé)收集轉(zhuǎn)化用戶的輸入。常用一個SERVLET來實現(xiàn)；View和Controller都依賴于Model，但是Model既不依賴于View，也不依賴于Controller，這是分離的主要優(yōu)點之一，這樣Model可以單獨的建立和測試以便于代碼復(fù)用，View和Controller只需要Model提供數(shù)據(jù)，它們不會知道、也不會關(guān)心數(shù)據(jù)是存儲在SQLServer還是Oracle數(shù)據(jù)庫中或者別的什么地方。4、WEB層框架StrutsStruts是一個在JSPModel2基礎(chǔ)上實現(xiàn)的MVC框架，其主要的設(shè)計理念是通過控制器將表現(xiàn)邏輯和業(yè)務(wù)邏輯解耦，以提高系統(tǒng)的可維護性、可擴展性及可重用性。Struts框架的體系結(jié)構(gòu)如下圖所示：下面就上圖所示的體系結(jié)構(gòu)圖分析Struts框架中的MVC組件。視圖(view)：視圖部分主要由JSP頁面組成，其中沒有流程邏輯、業(yè)務(wù)邏輯和模型信息，只有標(biāo)記。Struts自身包含了一組標(biāo)記庫(TagLib)，這也是Struts的精華之一，靈活運用它們可以簡化JSP頁面的代碼，提高開發(fā)效率。控制器(controller)：Struts中的Controller主要是其自身提供的ActionServlet。ActionServlet接收所有來自客戶端的請求并根據(jù)配置文件中的定義將控制轉(zhuǎn)移到適當(dāng)?shù)腁ction對象。模型(model)：Struts沒有定義具體Model層的實現(xiàn)，Model層通常是和業(yè)務(wù)邏輯緊密相關(guān)的，有持續(xù)化的要求。目前在商業(yè)領(lǐng)域和開源世界，都有一些優(yōu)秀的工具可以為Model層的開發(fā)提供便利。5、業(yè)務(wù)邏輯層框架SpringSpring是一個解決了許多JavaEE開發(fā)中常見問題并能夠替代EJB技術(shù)的強大的輕量級框架。這里所說的輕量級指的是Spring框架本身，而不是指Spring只能用于輕量級的應(yīng)用開發(fā)。Spring的輕盈體現(xiàn)在其框架本身的基礎(chǔ)結(jié)構(gòu)以及對其他應(yīng)用工具的支持和裝配能力。與EJB這種龐然大物相比，Spring可使程序研發(fā)人員把各個技術(shù)層次之間的風(fēng)險降低。Spring框架的核心是控制翻轉(zhuǎn)IoC(InversionofControl)/依賴注入DI(DependenceInjection)機制。IoC是指由容器中控制組件之間的關(guān)系（這里，容器是指為組件提供特定服務(wù)和技術(shù)支持的一個標(biāo)準化的運行時的環(huán)境）而非傳統(tǒng)實現(xiàn)中由程序代碼直接操控，這種將控制權(quán)由程序代碼到外部容器的轉(zhuǎn)移，稱為“翻轉(zhuǎn)”。DI是對IoC更形象的解釋，即由容器在運行期間動態(tài)地將依賴關(guān)系(如構(gòu)造參數(shù)、構(gòu)造對象或接口)注入到組件之中。Spring采用設(shè)值注入(使用Setter方法實現(xiàn)依賴)和構(gòu)造子注入(在構(gòu)造方法中實現(xiàn)依賴)的機制，通過配置文件管理組建的協(xié)作對象，創(chuàng)建可以構(gòu)造組件的IoC容器。這樣，不需要編寫工廠模式、單例模式或者其他構(gòu)造的方法，就可以通過容器直接獲取所需的業(yè)務(wù)組件。Spring框架的結(jié)構(gòu)如下圖所示。Spring框架由七個定義明確的模塊組成，且每個模塊或組件都可以單獨存在，或者與其他一個或多個模塊聯(lián)合實現(xiàn)。SpringCoreContainer是一個用來管理業(yè)務(wù)組件的IoC容器，是Spring應(yīng)用的核心；SpringDAO和SpringORM不僅提供數(shù)據(jù)訪問的抽象模塊，還集成了對Hibernate、JDO和iBatis等流行的對象關(guān)系映射框架的支持模塊，并且提供了緩沖連接池、事務(wù)處理等重要的服務(wù)功能，保證了系統(tǒng)的性能和數(shù)據(jù)的完整性；SprnigWeb模塊提供了Web應(yīng)用的一些抽象封裝，可以將Struts、Webwork等Web框架與Spring整合成為適用于自己的解決方案。Spring框架可以成為企業(yè)級應(yīng)用程序一站式的解決方案，同時它也是模塊化的框架，允許開發(fā)人員自由地挑選適合自己應(yīng)用的模塊進行開發(fā)。Spring框架式是一個松耦合的框架，框架的部分耦合度被設(shè)計為最小，在各個層次上具體選用哪個框架取決于開發(fā)者的需要。6、持久層框架HibernateO/Rmapping技術(shù)是為了解決關(guān)系型數(shù)據(jù)庫和面向?qū)ο蟮某绦蛟O(shè)計之間不匹配的矛盾而產(chǎn)生的。Hibernate是目前最為流行的O/Rmapping框架，它也是開源軟件,它在關(guān)系型數(shù)據(jù)庫和Java對象之間做了一個自動映射，使得程序員可以以非常簡單的方式實現(xiàn)對數(shù)據(jù)庫的操作，它不僅負責(zé)從Java類到數(shù)據(jù)庫表格(以及來自Java數(shù)據(jù)類型的SQL數(shù)據(jù)類型)的映射,而且還提供數(shù)據(jù)查詢和檢索能力，并能大大減少花在SQL和JDBC手工數(shù)據(jù)處理上的開發(fā)時間。Hibernate工作原理如下圖所示：Hibernate通過對JDBC的封裝，向程序員屏蔽了底層的數(shù)據(jù)庫操作，使程序員專注于OO程序的開發(fā)，有助于提高開發(fā)效率。程序員訪問數(shù)據(jù)庫所需要做的就是為持久化對象編制xml映射文件。底層數(shù)據(jù)庫的改變只需要簡單地更改初始化配置文件或者即可，不會對應(yīng)用程序產(chǎn)生影響。Hibernate有自己的面向?qū)ο蟮牟樵冋Z言HQL，HQL功能強大，支持目前大部分主流的數(shù)據(jù)庫，如Oracle、DB2、MySQL、MicrosoftSQLServer等，是目前應(yīng)用最廣泛的O/R映射工具。Hibernate為快速開發(fā)應(yīng)用程序提供了底層的支持?；赟SH框架的Web應(yīng)用架構(gòu)分析與設(shè)計前面分析了基于JavaEE的SSH框架技術(shù)，現(xiàn)代的企業(yè)開發(fā)中，越來越多地引入了多層架構(gòu)設(shè)計模式。SSH就是其中之一，SSH架構(gòu)是當(dāng)前主流的架構(gòu)，在很多領(lǐng)域，包括金融、電信項目，大型門戶網(wǎng)站均選擇該架構(gòu)作為業(yè)務(wù)支撐架構(gòu)，開發(fā)流程也已經(jīng)非常成熟。但是該結(jié)構(gòu)開發(fā)起來，依舊存在一些問題。分析這些問題，得先從SSH架構(gòu)的組成說起。SSH為Struts+Spring+Hibernate的組成方式，Struts實現(xiàn)MVC，Spring負責(zé)架構(gòu)的結(jié)合，Hibernate進行數(shù)據(jù)的持久化。通常其分層開發(fā)的結(jié)構(gòu)圖如下：這樣的結(jié)構(gòu)，系統(tǒng)從職責(zé)上分為四層：WEB層、業(yè)務(wù)邏輯層、數(shù)據(jù)持久層和實體層。其中使用Struts作為系統(tǒng)的整體基礎(chǔ)架構(gòu)，負責(zé)MVC的分離，在Struts框架的模型部分，利用Hibernate框架對持久層提供支持，業(yè)務(wù)層用Spring支持。具體做法是：用面向?qū)ο蟮姆治龇椒ǜ鶕?jù)需求提出一些模型，將這些模型實現(xiàn)為基本的Java對象，然后編寫基本的DAO接口，并給出Hibernate的DAO實現(xiàn)，采用Hibernate架構(gòu)實現(xiàn)的DAO類來實現(xiàn)Java類與數(shù)據(jù)庫之間的轉(zhuǎn)換和訪問，最后由Spring完成業(yè)務(wù)邏輯。系統(tǒng)的基本業(yè)務(wù)流程是：在WEB表示層中，首先通過JSP頁面實現(xiàn)交互界面，負責(zé)傳送請求(Request)和接收響應(yīng)(Response)，然后Struts根據(jù)配置文件將ActionServlet接收到的Request委派給相應(yīng)的Action處理。在業(yè)務(wù)層中，管理服務(wù)組件的SpringIoC容器負責(zé)向Action提供業(yè)務(wù)模型(Model)組件和該組件的協(xié)作對象數(shù)據(jù)處理(DAO)組件完成業(yè)務(wù)邏輯，并提供事務(wù)處理、緩沖池等容器組件以提升系統(tǒng)性能和保證數(shù)據(jù)的完整性。而在持久層中，則依賴于Hibernate的對象化映射和數(shù)據(jù)庫交互，處理DAO組件請求的數(shù)據(jù)，并返回處理結(jié)果。采用上述開發(fā)模型，不僅實現(xiàn)了視圖、控制器與模型的徹底分離，而且還實現(xiàn)了業(yè)務(wù)邏輯層與持久層的分離。這樣無論前端如何變化，模型層只需很少的改動，并且數(shù)據(jù)庫的變化也不會對前端有所影響，大大提高了系統(tǒng)的可復(fù)用性。而且由于不同層之間耦合度小，有利于團隊成員并行工作，大大提高了開發(fā)效率。但是對于當(dāng)前日益復(fù)雜化的的開發(fā)，卻存在不少問題，歸納起來主要有以下的不足：

DAO和服務(wù)層容易出現(xiàn)職責(zé)不明，由于按照MVC邏輯，業(yè)務(wù)代碼應(yīng)該寫在StrutsAction里，但是其事務(wù)的提供，卻是配置在Service層。為了一組在邏輯上完整的數(shù)據(jù)操作業(yè)務(wù)邏輯，需要涉及兩個層（Service、Action）來進行編寫，遇到判斷的情況下，為了保證完整的事務(wù)操作，則需要將業(yè)務(wù)代碼移到Service層完成，而通常習(xí)慣了在StrutsAction里調(diào)用多次Service而產(chǎn)生多個事務(wù),但在出現(xiàn)Exception導(dǎo)致出錯時,操作之前調(diào)用的Service事務(wù)的業(yè)務(wù)數(shù)據(jù)沒有被回滾。

當(dāng)需要返回的數(shù)據(jù)供AJAX使用，操作JSON或XML的大量使用時。開發(fā)起來會很費力，一段同樣的業(yè)務(wù)代碼，為了使用AJAX和XML可能需要重新編寫一次，或者在同一個ACTION里通過標(biāo)志來判斷，對分層結(jié)構(gòu)造成了比較糟糕的破壞。如果設(shè)計得不好，為了使用JSON和XML還得額外增加大量的配置，嚴重降低了開發(fā)效率。因此，為了克服這些缺點，對于SSH架構(gòu)，進行了重新的分層，共享了業(yè)務(wù)代碼。簡化了開發(fā)、增強了與AJAX技術(shù)、XML技術(shù)的結(jié)合。提供了一種更高效的開發(fā)模式。

其開發(fā)的結(jié)構(gòu)圖如下：這個架構(gòu)的優(yōu)點在于，由于業(yè)務(wù)代碼統(tǒng)一實現(xiàn)BusinessService接口，使得只需要相對固定的幾個StrutsAction類調(diào)用Service層的方法，便可以完成工作。包括JSON格式輸出，XML輸出及WebService輸出均調(diào)用Service層方法來完成功能。這樣便實現(xiàn)了業(yè)務(wù)代碼的分離，以及與前端框架的極大解耦。技術(shù)解決方案開發(fā)一款好的軟件產(chǎn)品，離不開一個好的開發(fā)過程。開發(fā)期間對過程的把控程度，往往會決定軟件產(chǎn)品的質(zhì)量好壞。因此，開發(fā)前期的計劃流程是必不可少的。本公司軟件系統(tǒng)的開發(fā)是按階段進行的，一般劃分為以下階段：可可行性分析需求分析概要設(shè)計詳細設(shè)計編碼測試修改完善驗收維護項目《可行性研究報告》《軟件需求說明書》《概要設(shè)計說明書》》《數(shù)據(jù)庫設(shè)計說明書》《詳細設(shè)計說明書》《測試計劃》《測試分析報告》》《驗收報告》《用戶操作手冊》1、可行性分析可行性分析的目的是明確系統(tǒng)的目的、功能和要求，了解目前所具備的開發(fā)環(huán)境和條件，分析的內(nèi)容有：①在技術(shù)能力上是否可以支持②在經(jīng)濟上效益如何③在法律上是否符合要求④與部門、企業(yè)的經(jīng)營和發(fā)展是否吻合⑤系統(tǒng)投入運行后的維護有無保障可行性討論的目的是判定軟件系統(tǒng)的開發(fā)有無價值，分析和討論的內(nèi)容形成“系統(tǒng)開發(fā)計劃書”，主要內(nèi)容有：(1)開發(fā)的目的及所期待的效果(2)系統(tǒng)的基本設(shè)想，涉及的業(yè)務(wù)對象和范圍(3)開發(fā)進度表，開發(fā)組織結(jié)構(gòu)(4)開發(fā)、運行的費用(5)預(yù)期的系統(tǒng)效益(6)開發(fā)過程中可能遇到的問題及注意事項。2、需求分析需求分析是軟件系統(tǒng)開發(fā)中最重要的一個階段，直接決定著系統(tǒng)的開發(fā)質(zhì)量和成敗。因此必須要明確用戶的要求和應(yīng)用現(xiàn)場環(huán)境的特點，了解系統(tǒng)應(yīng)具有哪些功能、數(shù)據(jù)的流程和數(shù)據(jù)之間的聯(lián)系。需求分析應(yīng)有用戶參加，到使用現(xiàn)場進行調(diào)研學(xué)習(xí)，軟件設(shè)計人員應(yīng)虛心向技術(shù)人員和使用人員請教，共同討論解決需求問題的方法，對調(diào)查結(jié)果進行分析，明確問題的所在。需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規(guī)格說明,評審。（一）、問題識別從系統(tǒng)角度來理解軟件,確定對所開發(fā)系統(tǒng)的綜合要求,并提出這些需求的實現(xiàn)條件,以及需求應(yīng)該達到的標(biāo)準。這些需求包括：功能需求(做什么),性能需求(要達到什么指標(biāo)),環(huán)境需求(如機型,操作系統(tǒng)等),可靠性需求(不發(fā)生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟件運行是所需的內(nèi)存,CPU等),軟件成本消耗與開發(fā)進度需求,預(yù)先估計以后系統(tǒng)可能達到的目標(biāo)。（二）、分析與綜合逐步細化所有的軟件功能,找出系統(tǒng)各元素間的聯(lián)系,接口特性和設(shè)計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分。最后,綜合成系統(tǒng)的解決方案,給出要開發(fā)的系統(tǒng)的詳細邏輯模型(做什么的模型)。（三）、制訂規(guī)格說明書即編制文檔,描述需求的文檔稱為軟件需求規(guī)格說明書。（四）、評審對功能的正確性,完整性和清晰性,以及其它需求給予評價。評審?fù)ㄟ^才可進行下一階段的工作,否則重新進行需求分析。需求分析的內(nèi)容最終會編寫成“系統(tǒng)需求分析報告”。3.系統(tǒng)設(shè)計（一）、設(shè)計原則和設(shè)計要求描述對本軟件系統(tǒng)進行概要設(shè)計的原則，通?？梢钥紤]以下幾方面的內(nèi)容：1、命名規(guī)則；2、模塊獨立性原則；3、邊界設(shè)計原則；4、數(shù)據(jù)庫設(shè)計規(guī)則；5、必須的安全措施；6、安全性和保密原則；7、系統(tǒng)靈活性要求；8、系統(tǒng)易操作性要求；9、系統(tǒng)可維護性要求；（二）、系統(tǒng)邏輯設(shè)計系統(tǒng)邏輯設(shè)計主要是根據(jù)軟件產(chǎn)品需求規(guī)格說明書和軟件產(chǎn)品數(shù)據(jù)字典建立系統(tǒng)的邏輯模型。此種模型暫時與系統(tǒng)的物理因素(例如：計算機、數(shù)據(jù)庫管理系統(tǒng))無關(guān)。它是系統(tǒng)需求與物理實現(xiàn)的中間結(jié)構(gòu)，它的主要結(jié)果是建立：系統(tǒng)結(jié)構(gòu)圖、系統(tǒng)界面結(jié)構(gòu)圖、系統(tǒng)出錯處理、以及系統(tǒng)開發(fā)技術(shù)說明。（三）、系統(tǒng)組織設(shè)計系統(tǒng)組織設(shè)計通過系統(tǒng)組織表描述本系統(tǒng)由哪些子系統(tǒng)(模塊)組成，這些子系統(tǒng)與業(yè)務(wù)職能之間的關(guān)系，以及各個子系統(tǒng)的安裝地點。系統(tǒng)組織表的格式如下：子系統(tǒng)編號英文名稱中文名稱業(yè)務(wù)職能安裝地點備注其中：1、子系統(tǒng)編號給出本系統(tǒng)中指定子系統(tǒng)的順序編號。如果本系統(tǒng)末劃分為多個子系統(tǒng)，僅由一個運行模塊組成；則本項內(nèi)容仍需要描述，但是本表內(nèi)容只有一行。在一個系統(tǒng)中有可能安裝若干個相同的子系統(tǒng)，在這種情況下，應(yīng)該視為一個子系統(tǒng)，并且對多個安裝地點分別進行描述。如果相同的子系統(tǒng)通過系統(tǒng)設(shè)置，實現(xiàn)的業(yè)務(wù)職能具有明顯差異時，應(yīng)該采用多行進行分別描述，并且在備注中說明其差異所在。2、子系統(tǒng)英文名稱給出本子系統(tǒng)的英文名稱，該名稱是在應(yīng)用軟件中實際使用的可執(zhí)行文件名稱，必須能夠說明該子系統(tǒng)的特點。若本系統(tǒng)中只有一個子系統(tǒng)，則本項內(nèi)容仍需要描述，但是本表內(nèi)容只有一行。3、子系統(tǒng)中文名稱給出本子系統(tǒng)的中文名稱，該名稱必須能夠說明該子系統(tǒng)的特點。若本系統(tǒng)中只有一個子系統(tǒng)，則本項內(nèi)容仍需要描述，但是本表內(nèi)容只有一行。4、業(yè)務(wù)職能描述該子系統(tǒng)完成的核心業(yè)務(wù)。5、安裝地點描述該子系統(tǒng)實際安裝的部門、或者某個具體地點。6、備注針對該子系統(tǒng)，需要說明的其它有關(guān)問題。（四）、系統(tǒng)結(jié)構(gòu)設(shè)計1、系統(tǒng)特性表系統(tǒng)特性是系統(tǒng)中完成某項具體操作的基本單元，它由入口參數(shù)，出口參數(shù)以及處理過程三部分組成。系統(tǒng)特性可以具有操作界面，也可以沒有操作界面；可以被其它操作界面、或者系統(tǒng)特性調(diào)用，也可以調(diào)用其它操作界面、非操作界面、或者系統(tǒng)特性；但是不允許遞歸調(diào)用(調(diào)用自己)，包括間接遞歸調(diào)用。當(dāng)系統(tǒng)由多個子系統(tǒng)(模塊)組成時，每個子系統(tǒng)分別使用一張系統(tǒng)特性表進行描述。系統(tǒng)特性表的格式如下：子系統(tǒng)編號：子系統(tǒng)英文名稱：子系統(tǒng)中文名稱：特性編號系統(tǒng)特征英文名稱系統(tǒng)特征中文名稱操作功能調(diào)用對象被調(diào)用對象備注說明：其中：（1）、子系統(tǒng)編號含義同上。（2）、子系統(tǒng)英文名稱含義同上。（3）、子系統(tǒng)中文名稱含義同上。（4）、特性編號整個系統(tǒng)所有特性的統(tǒng)一編號。（5）、系統(tǒng)特性英文名稱系統(tǒng)特性的英文正式名稱，將來用于軟件開發(fā)中，必須符合命名規(guī)范。（6）、系統(tǒng)特性中文名稱系統(tǒng)特性的中文正式名稱，來源于需求規(guī)格說明書中，系統(tǒng)特性一節(jié)中的有關(guān)描述。（7）、操作功能是指該特性實際完成的操作說明。（8）、調(diào)用對象是指調(diào)用該系統(tǒng)特性的系統(tǒng)對象，這里的系統(tǒng)對象可以是系統(tǒng)特性、也可以是操作界面。（9）、被調(diào)用對象是指被該系統(tǒng)特性調(diào)用的系統(tǒng)對象，這里的系統(tǒng)對象可以是系統(tǒng)特性、也可以是操作界面。（10）、備注描述與該系統(tǒng)特性有關(guān)的其它注意事項。（11）、說明描述與該系統(tǒng)特性表有關(guān)的其它注意事項。（五）、系統(tǒng)接口設(shè)計1、系統(tǒng)接口表接口作為系統(tǒng)的一種輸入／輸出形式，分為網(wǎng)絡(luò)接口、數(shù)據(jù)庫接口、RS-232串行通訊接口、IEEE—485串行總線接口、并行I/O接口等等多種類型。當(dāng)系統(tǒng)由多個子系統(tǒng)(模塊)組成時，每個子系統(tǒng)分別使用一張系統(tǒng)接口表進行描述。系統(tǒng)接口表的格式如下：子系統(tǒng)編號子系統(tǒng)英文名稱子系統(tǒng)中文名稱接口編號接口名稱接口類型接口性質(zhì)接口速率接口協(xié)議備注說明：其中：（1）、子系統(tǒng)編號含義同上。（2）、子系統(tǒng)英文名稱含義同上。（3）、子系統(tǒng)中文名稱含義同上。（4）、接口編號整個系統(tǒng)所有接口的統(tǒng)一編號。（5）、接口名稱系統(tǒng)接口的正式名稱，必須符合通常習(xí)慣。（6）、接口類型指出該接口所傳輸?shù)臄?shù)據(jù)在該模塊中起到的作用。（7）、接口性質(zhì)指出該接口在通訊中起到的作用，這里的作用可以是：輸入、輸出、雙向。（8）、接口速率指出該接口的傳輸速率。如果該接口依賴于其它通訊方式，那么傳輸速率將不高于它所依賴的其它通訊方式的速率。（9）、接口協(xié)議給出該接口實際使用的通訊協(xié)議。（10）、相關(guān)對象給出直接使用本接口的系統(tǒng)對象，這里的系統(tǒng)對象，可以是操作界面，也可以是系統(tǒng)特性。（11）、備注描述與該系統(tǒng)接口有關(guān)的其它注意事項。（12）、說明描述與該系統(tǒng)接口表有關(guān)的其它注意事項。（六）、系統(tǒng)完整性設(shè)計描述系統(tǒng)對象(數(shù)據(jù)元、數(shù)據(jù)類)，所受到的邏輯約束關(guān)系。當(dāng)系統(tǒng)由多個子系統(tǒng)(模塊)組成時，每個子系統(tǒng)應(yīng)分別使用一張系統(tǒng)完整性約束表進行描述。系統(tǒng)完整性約束表的格式如下：子系統(tǒng)編號子系統(tǒng)英文名稱子系統(tǒng)中文名稱約束編號完整性名稱相對對象名約束表達式備注說明：其中：（1）、子系統(tǒng)編號含義同上。（2）、子系統(tǒng)英文名稱含義同上。（3）、子系統(tǒng)中文名稱含義同上。（4）、約束編號整個系統(tǒng)所有約束的統(tǒng)一編號。（5）、完整性名稱系統(tǒng)完整性約束的正式名稱，必須符合通常習(xí)慣。（6）、相對對象名完整性約束中的相關(guān)對象(數(shù)據(jù)元和數(shù)據(jù)類)。（7）、約束表達式用一階邏輯表達式表達的約束方程式。（8）、備注描述與該系統(tǒng)完整性約束有關(guān)的其它注意事項。（9）、說明描述與該系統(tǒng)完整性約束表有關(guān)的其它注意事項。系統(tǒng)設(shè)計具體可根據(jù)系統(tǒng)的規(guī)模分成概要設(shè)計和詳細設(shè)計兩個階段，概要設(shè)計包括：①劃分系統(tǒng)模塊②每個模塊的功能確定③用戶使用界面概要設(shè)計④輸入輸出數(shù)據(jù)的概要設(shè)計⑤報表概要設(shè)計⑥數(shù)據(jù)之間的聯(lián)系、流程分析⑦文件和數(shù)據(jù)庫表的邏輯設(shè)計⑧硬件、軟件開發(fā)平臺的確定⑨有規(guī)律數(shù)據(jù)的規(guī)范化及數(shù)據(jù)惟一性要求。系統(tǒng)的詳細設(shè)計是對系統(tǒng)的概要設(shè)計進一步具體化，其主要工作有：①文件和數(shù)據(jù)庫的物理設(shè)計②輸入輸出記錄的方案設(shè)計③對各子系統(tǒng)的處理方式和處理內(nèi)容進行細化設(shè)計④編制程序設(shè)計任務(wù)書。程序說明書通常包括程序規(guī)范、功能說明、程序結(jié)構(gòu)圖，通常用HPIPO（HierarchyPlusInputProcessOutput）圖描述。4、編碼根據(jù)程序設(shè)計任務(wù)書的要求，用計算機算法語言實現(xiàn)解題的步驟，主要工作包括：①模塊的理解和進一步劃分②以模塊為單位的邏輯設(shè)計，也就是模塊內(nèi)的流程圖的編制③編寫代碼，用程序設(shè)計語言編制程序④進行模塊內(nèi)功能的測試、單元測試。程序質(zhì)量的要求包括：①滿足要求的確切功能②處理效率高③操作方便，用戶界面友好④程序代碼的可讀性好，函數(shù)、變量標(biāo)識符合規(guī)范⑤擴充性、維護性好。降低程序的復(fù)雜性也是十分重要的，系統(tǒng)的復(fù)雜性由模塊間的接口數(shù)來衡量，一般地講，n個模塊的接口數(shù)的最大值為n(n-1)/2；若是層次結(jié)構(gòu)，n個模塊的接口數(shù)的最小值為n-1。為使復(fù)雜性最小，對模塊的劃分設(shè)計常常采用層次結(jié)構(gòu)。要注意編制的程序或模塊應(yīng)容易理解、容易修改，模塊應(yīng)相互獨立，對某一模塊的修改應(yīng)對其他模塊的功能不產(chǎn)生影響，模塊間的聯(lián)系盡可能少。5.系統(tǒng)測試測試是為了發(fā)現(xiàn)程序中的錯誤，對于設(shè)計的軟件，出現(xiàn)錯誤是難免的。系統(tǒng)測試通常由經(jīng)驗豐富的設(shè)計人員設(shè)計測試方案和測試樣品，并寫出測試過程的詳細報告。系統(tǒng)測試是在單元測試的基礎(chǔ)上進行的，包括：①測試方案的設(shè)計；②進行測試；③寫出測試報告；④用戶對測試結(jié)果進行評價。具體測試方式如下：黑盒測試黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結(jié)構(gòu)。測試者把被測程序看成一個黑盒,不用關(guān)心程序的內(nèi)部結(jié)構(gòu)。黑盒測試是在程序接口處進行測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性。黑盒測試是基于用戶角度進行的測試。白盒測試本公司系統(tǒng)軟件測試的主要方法之一，也稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內(nèi)部結(jié)構(gòu)、算法等信息，這是從程序設(shè)計者的角度對程序進行的測試。它的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題?；液袦y試可以理解為靜態(tài)的白盒測試或動態(tài)的黑盒測試，灰盒就是界于黑白之間,對軟件內(nèi)部有所了解,但不見得到了如指掌的程度,卻可以結(jié)合這些了解做些比黑盒多點的測試。文檔測試文檔測試涵蓋面很大，在軟件的各個版本中均有所使用。隨著軟件版本的變化，文檔測試的測試內(nèi)容也有所變化。在需求分析以及原型架構(gòu)階段，文檔測試主要目標(biāo)是：Sitemap、動作分解列表、數(shù)據(jù)庫ER圖、UML用例圖、流程圖、需求文檔等文檔。文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內(nèi)容前后矛盾。完整性是指文檔不可以漏掉關(guān)鍵性內(nèi)容?？衫斫庑允侵冈谖臋n中描述的語言要簡明易懂，不能讓別的開發(fā)人員拿到文檔時看不懂文檔的內(nèi)容。命名規(guī)范測試命名規(guī)范測試用于測試項目中的文件命名、代碼以及版本號等書寫是否符合規(guī)范。需求完整性測試需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認需求是否明確。另外，需求完整性測試也承擔(dān)著一部分澄清需求的任務(wù)。鏈接完整性測試在原型架構(gòu)階段，鏈接完整性的測試是非常有必要的。該項測試任務(wù)主要是檢查假頁面中各種鏈接是否完整，是否指向目標(biāo)位置，屬于檢查性的測試。頁面完整性測試頁面完整性測試主要存在于集成測試階段以及其后續(xù)其它階段中，測試頁面是否完整，頁面質(zhì)量是否達標(biāo)，屬于檢查性測試。UI合理性測試UI合理性測試也就是人機交互界面的合理性，UI合理性測試的內(nèi)容很多，具體測試內(nèi)容如下：提示、菜單、幫助的格式是否一致；提示、菜單、幫助中的術(shù)語是否一致；各個控件之間的對齊方式是否一致；輸入界面和輸出界面在外觀、布局、交互方式上是否一致；功能類似的相關(guān)界面在外觀、布局、交互方式上是否一致；同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小是否與界面的大小比例協(xié)調(diào)；多個連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致；系統(tǒng)是否拒絕客戶的錯誤輸入并做出提示；系統(tǒng)是否在用戶完成操作時給出操作成功的提示；用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差；各個控件的間隔是否一致，垂直和水平方向上是否對齊；是否允許動作的可逆性，返回原有操做；數(shù)據(jù)和數(shù)據(jù)庫完整性測試在開發(fā)階段開發(fā)人員隨時都有可能根據(jù)需要來修改數(shù)據(jù)庫，所以對數(shù)據(jù)和數(shù)據(jù)庫完整性測試在軟件項目的任何階段也是非常必要的。該項測試內(nèi)容主要是以數(shù)據(jù)庫表為單位，檢查數(shù)據(jù)庫表以及表中各字段命名是否符合命名規(guī)范，表中字段是否完整，數(shù)據(jù)庫表中的字段描述是否正確包括字段的類型、長度、是否為空，數(shù)據(jù)庫表中的關(guān)系、索引、主鍵、約束是否正確。功能測試功能測試在軟件項目的任何階段中都是重要的。實現(xiàn)功能，滿足客戶需求是軟件本身最大的使命。功能測試在任何階段下基本上都作為測試工作的第一項出現(xiàn)。該項測試任務(wù)主要為了測試已實現(xiàn)的功能是否滿足需求，是否正確，是否有價值以及是否完整。在黑盒和白盒測試狀態(tài)下，該測試均會被使用。功能測試中測試人員往往會忽略掉一些細節(jié)問題，比如：一個功能的實現(xiàn)必須要經(jīng)過6步操作才能完成，而且需要加入20條信息才能看得出測試結(jié)果，有的測試人員為了節(jié)省時間雖然做完了6步操作，但是沒有加入足量的信息,使得測試不全面,正是因為這樣而導(dǎo)致一些隱藏的BUG沒有被測試出來。所以說在功能測試中要按部就班的把所有要進行的測試功能每一步都執(zhí)行一遍，應(yīng)該添加的數(shù)據(jù)都添加完整，以避免遺漏掉BUG沒有測試出來。壓力測試壓力測試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會變得不可接受。這通過改變應(yīng)用程序的輸入以對應(yīng)用程序施加越來越大的負載并測量在這些不同的輸入時性能的改變來實現(xiàn)的。這種操作也稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試——增加用戶數(shù)量以對應(yīng)用程序進行壓力測試。對應(yīng)用程序進行壓力測試最簡單的方法是手工改變輸入（客戶機數(shù)量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內(nèi)改變輸入，那么你可以借助一個自動化的壓力測試工具來完成此測試。安全性測試安全性測試主要是測試系統(tǒng)在沒有授權(quán)的內(nèi)部或者外部用戶對系統(tǒng)進行攻擊或者惡意破壞時如何進行處理，是否仍能保證數(shù)據(jù)和頁面的安全。測試人員可以學(xué)習(xí)一些黑客技術(shù)，來對系統(tǒng)進行攻擊。另外，對操作權(quán)限的測試也包含在安全性測試中。具體測試內(nèi)容如下：執(zhí)行添加、刪除、修改等動作中是否做過登錄檢測。退出系統(tǒng)之后的操作是否可以完成。所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲，特殊字符為：！#￥%……—*（）~——-+=[]{}、|；：‘”/《》<>，。

在帶有參數(shù)的回顯數(shù)據(jù)的動作中更改參數(shù)，把參數(shù)改為特殊字符并加入操作語句看是否出錯。測試表單中有沒有做標(biāo)簽檢測，標(biāo)簽檢測是否完整。在插入表單中加入特殊的HTML代碼，例如：<marquee>表單中的字本是否移動？</marquee>。頁面腳本測試頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進行測試。其主要內(nèi)容包括：相關(guān)頁面中的腳本是否正常運行，JavaScript腳本是否有錯誤頁面。提示文本測試提示文本測試從嚴格意義上來講應(yīng)該屬于UI合理性測試的一部分，該項測試主要針對各個頁面中使用到的大量提示文檔進行測試，主要包括：表達不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。瀏覽器測試由于B/S結(jié)構(gòu)項目是基于瀏覽器運行的，所以需要對瀏覽器進行必要的測試。該測試任務(wù)主要是軟件對各種瀏覽器（、、FireFox瀏覽器）的支持是否正常，在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。安裝測試在軟件項目的后期階段，會對做好的軟件進行打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進行安裝功能方面的測試。該測試的主要任務(wù)是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。6、文檔資料文檔包括開發(fā)過程中的所有技術(shù)資料以及用戶所需的文檔，軟件系統(tǒng)的文檔一般可分為系統(tǒng)文檔和用戶文檔兩類。用戶文檔主要描述系統(tǒng)功能和使用方法，并不考慮這些功能是怎樣實現(xiàn)的，系統(tǒng)文檔描述系統(tǒng)設(shè)計、實現(xiàn)和測試等方面的內(nèi)容。文檔是影響軟件可維護性、可用性的決定因素，有句話講，系統(tǒng)編程人員的每一張紙片都要保留，所以文檔的編制是軟件開發(fā)過程中的一項重要工作。系統(tǒng)文檔包括：①開發(fā)軟件系統(tǒng)在計劃②需求分析③設(shè)計④編制⑤調(diào)試⑥運行等階段的有關(guān)文檔。在對軟件系統(tǒng)進行修改時，系統(tǒng)文檔應(yīng)同步更新，并注明修改者和修改日期，如有必要應(yīng)注明修改原因，應(yīng)切記過時的文檔是無用的文檔。用戶文檔包括：①系統(tǒng)功能描述②安裝文檔，說明系統(tǒng)安裝步驟以及系統(tǒng)的硬件配置方法③用戶使用手冊，說明使用軟件系統(tǒng)方法和要求，疑難問題解答④參考手冊，描述可以使用的所有系統(tǒng)設(shè)施，解釋系統(tǒng)出錯信息的含義及解決途徑。7、系統(tǒng)的運行與維護系統(tǒng)只有投入運行后，才能進一步對系統(tǒng)檢驗，發(fā)現(xiàn)潛在的問題，為了適應(yīng)環(huán)境的變化和用戶要求的改變，可能會對系統(tǒng)的功能、使用界面進行修改。要對每次發(fā)現(xiàn)的問題和修改內(nèi)容建立系統(tǒng)維護文檔，并使系統(tǒng)文檔資料同步更新。服務(wù)保證措施本公司軟件質(zhì)量保證由各項任務(wù)構(gòu)成，這些任務(wù)的參與者有兩種人：軟件開發(fā)人員和質(zhì)量保證人員。前者負責(zé)技術(shù)工作，后者負責(zé)質(zhì)量保證的計劃、監(jiān)督、記錄、分析及報告工作。軟件開發(fā)人員通過采用可靠的技術(shù)方法和措施，進行正式的技術(shù)評審，執(zhí)行計劃周密的軟件測試來保證軟件產(chǎn)品的質(zhì)量。軟件質(zhì)量保證人員則輔助軟件開發(fā)組得到高質(zhì)量的最終產(chǎn)品。我們的軟件質(zhì)量保證計劃大體分為如下三大部分：把軟件研制合理地劃分為若干階段，并針對每個階段的特點,制定出質(zhì)量評審、評測的要求和措施。從軟件質(zhì)量的要求出發(fā),制定出相應(yīng)的技術(shù)和管理規(guī)范，如軟件文檔規(guī)范、軟件編程規(guī)范、軟件測試規(guī)范、軟件版本控制規(guī)范等。創(chuàng)建和積累公用模塊，向軟件工廠化方向發(fā)展。1、軟件研制的階段劃分及其質(zhì)量控制我們把軟件系統(tǒng)的研制劃分為8個階段，即總體需求分析、總體設(shè)計、各分系統(tǒng)的需求說明及概要設(shè)計、詳細設(shè)計(面向子系統(tǒng))、程序編制、自測試、組裝與驗收測試、試用和初步定型。我們規(guī)定，總體需求分析及總體設(shè)計需經(jīng)有關(guān)領(lǐng)導(dǎo)及管理專家評審認定。分系統(tǒng)的需求說明、概要設(shè)計及詳細設(shè)計需經(jīng)總工程師組織的技術(shù)評審組評審。評審前，多數(shù)分系統(tǒng)的需求說明及概要設(shè)計需經(jīng)有代表性的用戶審核認可，即分析和設(shè)計階段主要靠評審把關(guān)，編程和實施階段主要靠執(zhí)行規(guī)范和測試把關(guān)。每次評審的結(jié)果都有相應(yīng)的記錄，并填寫相應(yīng)的表格。2、軟件的文檔規(guī)范系統(tǒng)開發(fā)的文檔要求是：每個分系統(tǒng)必須有需求說明、概要設(shè)計，每個子系統(tǒng)必須有詳細設(shè)計和操作使用說明。需求說明、概要設(shè)計和詳細設(shè)計必須串行完成，而且規(guī)定，詳細設(shè)計未經(jīng)評審?fù)ㄟ^不能進入正規(guī)編程。不寫設(shè)計就進入編程，這是軟件開發(fā)人員常犯的毛病，在我們的系統(tǒng)開發(fā)中這是不允許的。3、軟件編程規(guī)范開發(fā)中所有設(shè)計文件經(jīng)過認真的評審、推敲和認定后，軟件編程將是保證軟件質(zhì)量的一個重要環(huán)節(jié)。為保證這一環(huán)節(jié)的質(zhì)量，我們專門制定了編程的有關(guān)規(guī)范。其中最主要的是界面規(guī)范。需要強調(diào)的是，對界面的理解不應(yīng)只限于屏幕格式和操作方法，界面設(shè)計應(yīng)貫穿于軟件編制的全過程，我們的界面規(guī)范分為兩大部分：第一部分是設(shè)計原則，包括：一般原則、屏幕格式設(shè)計原則、輸入過程設(shè)計原則、信息顯示設(shè)計原則、提示信息設(shè)計原則、報表設(shè)計原則、菜單設(shè)計原則、操作方法原則。它重點解決操作的方便性和直接性、顯示和提示的確定性、輸入的準確性、輸入輸出的一致性，以保證對用戶習(xí)慣和心理的良好適應(yīng)性，給用戶一種愉快感，讓用戶產(chǎn)生一種喜愛感。第二部分是屏幕格式設(shè)計，包括：版權(quán)屏幕、登錄屏幕、單記錄錄入窗口、多記錄錄入窗口、查詢列表窗口、主/細數(shù)據(jù)錄入窗口、命令按鈕格式。它的主要目標(biāo)是，力求使屏幕格式簡煉、實用、直觀、醒目、格調(diào)一致，使操作使用方便。軟件編程規(guī)范更是一種設(shè)計和編程經(jīng)驗的總結(jié)，是對所用開發(fā)工具的深入認識和全面理解。這一規(guī)范本身的質(zhì)量直接關(guān)系到全系統(tǒng)的編程效率和可移植性、軟件的可擴展性及可維護性、數(shù)據(jù)的可恢復(fù)性和系統(tǒng)的可靠性。特別是在客戶/服務(wù)器模式下工作的系統(tǒng)，編程時對處理和數(shù)據(jù)的合理分布將直接影響到系統(tǒng)資源利用得是否充分、恰當(dāng)，直接影響到整個系統(tǒng)的性價比。它包括：對象和控制命名規(guī)范、編程風(fēng)格、數(shù)據(jù)校驗、環(huán)境配置與應(yīng)用的可移植性、事件驅(qū)動、面向?qū)ο?、?shù)據(jù)庫訪問規(guī)范、數(shù)據(jù)及處理分布、出錯處理、安裝及設(shè)置。實踐證明，這一規(guī)范對保證程序質(zhì)量、提高軟件重用度,進而對提高編程效率、乃至提高系統(tǒng)的可靠性均起了重要作用。4、軟件測試規(guī)范軟件測試是在設(shè)計階段保證軟件質(zhì)量的最后一關(guān)。從測試手段來說，我們把整個測試分為白盒測試和黑盒測試，并在軟件編制過程中交叉使用。指派對開發(fā)工具認識最深入、編程經(jīng)驗最豐富的同志從事白盒測試；指派對工作流程最熟悉、對操作使用研究和體會最細致的同志從事黑盒測試。從測試過程來說，又分為兩步：自測試和組裝驗收測試。自測試是軟件編制者自己設(shè)計測試用例，自己驗證；組裝和驗收測試則是按照需求說明和工作流程全面設(shè)計測試案例，進行全面測試。工作流程、數(shù)據(jù)流程、各子系統(tǒng)之間及各模塊之間的接口是驗收測試的重點之一。整個測試階段必然是一個發(fā)現(xiàn)問題→修改完善→再測試的過程，而且可能多次反復(fù)。此時，最重要的是要把握住兩點：一是每提出一個修改，都需經(jīng)過總體設(shè)計師和分系統(tǒng)設(shè)計者的認真研究討論，既要保證軟件的正確性、流程的合理性和功能的完備性，又要保證總體設(shè)計思想和軟件設(shè)計風(fēng)格不受破壞，即保證軟件的整體質(zhì)量；二是程序編制者和測試者都要有足夠的耐心和良好的協(xié)作精神，都要有對軟件質(zhì)量負責(zé)的責(zé)任感。無論自測試，還是組裝及驗收測試，都是極其細致而又繁瑣的過程。不少技術(shù)人員愿意搞設(shè)計和編程，而不愿在測試方面多花功夫。軟件開發(fā)的管理者對這種傾向需嚴密注視、盡力防范，同時應(yīng)做出具體規(guī)定，作為軟件設(shè)計的法規(guī)，要求大家嚴格遵守。測試規(guī)范的概要如下在自測試階段制定了自測試方法和自測試過程。自測試方法重點規(guī)定了兩點：一是白盒測試、人工審查與機器執(zhí)行相結(jié)合；二是給出了測試用例設(shè)計原則，即模塊內(nèi)部和模塊間的測試用例設(shè)計原則及重點檢查的內(nèi)容。自測試過程分為代碼審查、模塊測試、組裝測試和整理測試報告四個過程。規(guī)范中詳細規(guī)定了每一過程的細節(jié)和要求。組裝及驗收測試規(guī)范中同樣規(guī)定了測試方法和測試過程。其中，重點強調(diào)三點：一是再次推敲流程是否合理，功能是否齊全；二是測試用例設(shè)計必須考慮如下幾方面要求：功能測試、性能測試、大數(shù)據(jù)量測試、可靠性測試、可恢復(fù)性測試、多用戶測試、安裝測試和配置測試；三是要重視模塊和子系統(tǒng)之間的接口測試。5、軟件版本控制版本控制是對已做成的軟件在發(fā)展過程中的一種質(zhì)量管理，各大公司對自己的軟件均有一套版本控制方法。我們開發(fā)的軟件系統(tǒng)絕不是“一錘子買賣”，推出了第一期軟件的試用版，還會有第二期軟件補充進來，兩期軟件到一定階段都將定為正式版，而且今后還會繼續(xù)發(fā)展，到一定時候還要更新。何時定為正式版，何時宣布版本升級，都需要有明確的要求和界限，兩個版本之間的任何修改和維護都需要一套管理辦法。升級也好，更新也好，都需要考慮與原來版本的兼容，以保護用戶的投資利益。6、建立公共模塊，向工廠化方向發(fā)展盡管一套軟件系統(tǒng)可分為若干分系統(tǒng)和子系統(tǒng)，但它們?nèi)詴幸恍┕餐蝾愃频牟僮鳌⒐餐僮鞒槿〕鰜?，制成若干公用模塊，供各子系統(tǒng)調(diào)用或直接使用，這不僅可提高軟件的編程效率，也直接提高了軟件質(zhì)量。這雖屬于總體設(shè)計和總體規(guī)劃中的工作，但從質(zhì)量管理的角度重視這一工作，把它作為軟件質(zhì)量保證的一項措施，也很有意義。技術(shù)培訓(xùn)計劃概述人員培訓(xùn)作為工程實施的一個重要環(huán)節(jié)，對整個項目的實施至關(guān)重要，通過系統(tǒng)的培訓(xùn)，使得工作人員得到日常工作需要的專業(yè)技術(shù)知識和經(jīng)驗，從而保障整個系統(tǒng)的順利運行。項目建設(shè)最終系統(tǒng)將交付用戶使用，項目培訓(xùn)是項目實施中的重要環(huán)節(jié)，通過項目培訓(xùn)對業(yè)主人員進行全面的技術(shù)培訓(xùn)，使業(yè)主單位人員達到能獨立進行管理、故障處理、日常測試維護等工作，以便于我方提供的軟、硬件能夠正常、安全的運行。培訓(xùn)的總體目標(biāo)：1、管理員培訓(xùn)。培訓(xùn)對象：系統(tǒng)管理員。培訓(xùn)目的：可以獨立完成本單位行政執(zhí)法的日常維護，解決一般問題。培訓(xùn)內(nèi)容：系統(tǒng)體系結(jié)構(gòu)、系統(tǒng)配置、系統(tǒng)管理、系統(tǒng)使用。培訓(xùn)方式：集中培訓(xùn)和個別培訓(xùn)。培訓(xùn)批次：不少于1次的集中培訓(xùn)，個別培訓(xùn)隨時安排。2、使用人員培訓(xùn)培訓(xùn)對象：系統(tǒng)一般使用人員。培訓(xùn)目的：熟練掌握所涉及部分的操作。培訓(xùn)內(nèi)容：系統(tǒng)使用。培訓(xùn)方式：集中培訓(xùn)和個別培訓(xùn)。培訓(xùn)批次：不少于2次的集中培訓(xùn)，個別培訓(xùn)隨時安排。培訓(xùn)對象如果項目是一項綜合型的項目，系統(tǒng)使用范圍廣，用戶層次多，不同用戶層次使用的系統(tǒng)角色不相同，使用的內(nèi)容和側(cè)重點各不相同，那么我們在項目中將針對不同的用戶層次提供針對性的用戶培訓(xùn)，保障培訓(xùn)效果，使各層次的用戶都能熟練掌握系統(tǒng)相關(guān)的知識。普通用戶層普通用戶層是應(yīng)用系統(tǒng)的直接使用者，涉及到系統(tǒng)的各方面功能，是對系統(tǒng)功能理解最深、業(yè)務(wù)最熟悉的用戶群，然而普通用戶層由于覆蓋的面廣，各部門主要使用的功能模塊不盡相同，因此針對于普通用戶將按照不同的部門的側(cè)重點進行分期培訓(xùn)，組織類似業(yè)務(wù)部門或單獨部門進行培訓(xùn)，以便于各部門對各自業(yè)務(wù)系統(tǒng)使用的把握，以達到各用戶能熟練掌握系統(tǒng)的使用方法。系統(tǒng)管理員和應(yīng)用級管理員系統(tǒng)管理員和應(yīng)用級管理員是業(yè)主單位對系統(tǒng)進行管理維護的主要人員，這一用戶群掌握一定的信息技術(shù)，并且針對應(yīng)用系統(tǒng)管理員和平臺維護員分別進行針對性的培訓(xùn)，主要側(cè)重于系統(tǒng)的建設(shè)原理和規(guī)劃，總體架構(gòu)，常見問題的解決，系統(tǒng)安裝配置等內(nèi)容。系統(tǒng)的維護和管理工作需要對應(yīng)用系統(tǒng)較熟悉，并且能處理運行過程中遇到的各類問題，因此對于軟件維護人員和管理員將采用共同參與項目維護和實施的方式，從長期實踐中逐漸掌握系統(tǒng)維護知識，提升其技術(shù)技能和對系統(tǒng)的認識。技術(shù)人員培訓(xùn)技術(shù)人員主要是指業(yè)主單位具備一定的應(yīng)用系統(tǒng)開發(fā)能力，主要用于系統(tǒng)上線后對系統(tǒng)的需求變動進行二次開發(fā)和修改，以及系統(tǒng)擴展能力的技術(shù)人員，針對這一用戶群，將著重于應(yīng)用系統(tǒng)的開發(fā)原理、開發(fā)工具、系統(tǒng)架構(gòu)等進行培訓(xùn)，使其掌握系統(tǒng)二次開發(fā)技術(shù)，為今后系統(tǒng)升級改造、功能擴展儲備技術(shù)力量。培訓(xùn)課程應(yīng)用系統(tǒng)使用培訓(xùn)課程名：系統(tǒng)應(yīng)用。課程內(nèi)容：計算機系統(tǒng)基本操作方法；系統(tǒng)基本功能介紹；業(yè)務(wù)流程規(guī)范；系統(tǒng)使用方法。課時：1天。系統(tǒng)運維技術(shù)培訓(xùn)課程名：日常維護培訓(xùn)。課程內(nèi)容：系統(tǒng)總體邏輯及工作原理；系統(tǒng)基本功能介紹；可視化流程定制工具使用方法；可視化表單定制工具使用方法；系統(tǒng)的部署，應(yīng)用的安裝，系統(tǒng)的使用、配置、管理和備份，系統(tǒng)日常維護任務(wù)；系統(tǒng)故障處置方法。課時：4天。項目管理初級（可選）課程名：項目管理初級。課程內(nèi)容：項目管理基本知識；項目管理方法；項目管理工具應(yīng)用。課時：1天。系統(tǒng)支撐軟、硬件環(huán)境應(yīng)用管理課程名：系統(tǒng)支撐軟、硬件環(huán)境應(yīng)用管理。課程內(nèi)容：操作系統(tǒng)安裝、配置和管理；數(shù)據(jù)庫安裝、配置和管理；支撐環(huán)境常規(guī)故障處置方法。課時：3天。系統(tǒng)設(shè)計與開發(fā)基礎(chǔ)（可選）課程名：系統(tǒng)設(shè)計與開發(fā)。課程內(nèi)容：系統(tǒng)設(shè)計基礎(chǔ)；開發(fā)工具使用初步；系統(tǒng)開發(fā)規(guī)范；數(shù)據(jù)庫設(shè)計基礎(chǔ)；系統(tǒng)二次開發(fā)方法。課時：5天。培訓(xùn)組織保障公司會建立專業(yè)的項目培訓(xùn)小組，人員配置如下：項目培訓(xùn)組組長：1人培訓(xùn)講師：2人；培訓(xùn)監(jiān)督員：1人；培訓(xùn)資料管理員：1人；培訓(xùn)組織人員：1人；教學(xué)方案如果項目是一個綜合型的項目，培訓(xùn)對象層次分明，培訓(xùn)內(nèi)容多樣，且在系統(tǒng)上線培訓(xùn)期間各用戶還有自身的事務(wù)需要處，那么公司會在培訓(xùn)過程中將針對不同的用戶和不同的培訓(xùn)內(nèi)容采用不同的培訓(xùn)方案，以達到最佳的培訓(xùn)效果，培訓(xùn)方案如下圖所示：實踐培訓(xùn)實踐培訓(xùn)是指在項目實施過程中與我方工程師一道參與項目研發(fā)和實施過程，在實踐過程中逐漸掌握培訓(xùn)內(nèi)容。實踐培訓(xùn)主要針對于技術(shù)開發(fā)人員及系統(tǒng)維護和管理人員。在項目實施之初即邀請技術(shù)開發(fā)人員與我公司開發(fā)人員一起參與項目開發(fā)過程，從大量的實踐過程中獲取開發(fā)知識，以便于對系統(tǒng)的設(shè)計、開發(fā)語言、系統(tǒng)架構(gòu)熟悉，為業(yè)主單位培養(yǎng)較全面，對系統(tǒng)理解較深的專業(yè)技術(shù)人員。集中培訓(xùn)集中培訓(xùn)將培訓(xùn)對象集中，以授課的方式進行培訓(xùn)。這類培訓(xùn)主要針對于培訓(xùn)用戶較多，培訓(xùn)內(nèi)容較單一的內(nèi)容進行，如最終用戶使用培訓(xùn)。通過演示和現(xiàn)場交流的方式達到培訓(xùn)效果。研討會在項目實施過程將不定期進行研討會。召集技術(shù)相關(guān)人員或業(yè)務(wù)處理人員，針對技術(shù)的發(fā)展和業(yè)務(wù)模型的處理通過交流的方式進行討論，在研討會上將邀請業(yè)界的專家列席，以便于相互之間的交流，對參與交流會的人員提供技術(shù)咨詢和指導(dǎo)，促進業(yè)主單位技術(shù)和業(yè)務(wù)水平的提高。遠程培訓(xùn)當(dāng)培訓(xùn)用戶無法集中，或聘請遠程專家進行培訓(xùn)時，我們將采用網(wǎng)絡(luò)培訓(xùn)的方式完成遠程培訓(xùn)工作。一對一培訓(xùn)一對一培訓(xùn)主要針對于統(tǒng)一培訓(xùn)時無法參加、未掌握培內(nèi)容或個別特殊用戶如領(lǐng)導(dǎo)、唯一的系統(tǒng)管理員、特殊的業(yè)務(wù)操作人員等，進行一對一的單獨培訓(xùn)。培訓(xùn)規(guī)模設(shè)定建議培訓(xùn)的規(guī)模大小主要看受訓(xùn)的人數(shù)和受訓(xùn)次數(shù)，百人以上就可算是較大規(guī)模的培訓(xùn)。從培訓(xùn)的效果來看，一次性受訓(xùn)的人數(shù)超過40人后，培訓(xùn)的效果下降地越快。一次性受訓(xùn)的人數(shù)為20人，培訓(xùn)的效果和效率是相對最佳的。所以對于大型軟件的培訓(xùn)，在受訓(xùn)人數(shù)較多的情況下，常用的辦法是：化整為零，將受訓(xùn)人員分為20-40個人一批，進行分批、分時或同時進行培訓(xùn)，不宜進行大課培訓(xùn)。同時針對培訓(xùn)對