1、軟件項目招標文件技術標書（最全最詳細）供應商針對本項目技術服務類總體要求的理解在軟件開發的過程中，我們一向遵循軟件產品的以下原則：1、功能性:與一組功能及其指定的性質有關的一組屬性，具體包括：適合性:與規定任務能否提供一組功能以及這組功能的適合程度有關的軟件屬性準確性:與能否得到正確或相符的結果或效果有關的軟件屬性互用性:與同其他指定系統進行交互的能力有關的軟件屬性依從性:使軟件遵循有關的標準，約定，法規及類似規定的軟件屬性安全性:與防止對程序及數據的非授權的故意或意外訪問的能力有關的軟件屬性2、可靠性:與在規定的一段時間和條件下，軟件維持其性能水平的能力有關的一組屬性，具體包括：成熟性:與由

2、軟件故障引起失效的頻度有關的軟件屬性容錯性:與在軟件故障或違反指定接口的情況下，維持規定的性能水平的能力有關的軟件屬性易恢復性:與在失效發生后，重建其性能水平并恢復直接受影響數據的能力以及為達此目的所需的時間和能力有關的軟件屬性3、易用性:與一組規定或潛在的用戶為使用軟件所需作的努力和對這樣的使用所作的評價有關的一組屬性，具體包括：易理解性:與用戶為認識邏輯概念及其應用范圍所花的努力有關的軟件屬性易學性:與用戶為學習軟件應用所花的努力有關的軟件屬性易操作性:與用戶為操作和運行控制所花努力有關的軟件屬性4、效率:與在規定的條件下，軟件的性能水平與所使用資源量之間關系有關的一組屬性，具體包括時間特

3、性:與軟件執行其功能時響應和處理時間以及吞吐量有關的軟件屬性資源特性:與在軟件執行其功能時所使用的資源數量及其使用時間有關的軟件屬性5、可維護性：與進行指定的修改所需的努力有關的一組屬性，具體包括：易分析性:與為診斷缺陷或失效原因及為判定待修改的部分所需努力有關的軟件屬性易改變性:與進行修改，排除錯誤或適應環境變化所需努力有關的軟件屬性穩定性:與修改所造成的未預料結果的風險有關的軟件屬性易測試性:與確認已修改軟件所需的努力有關的軟件屬性6、可移植性：與軟件可從某一環境轉移到另一環境的能力有關的一組屬性，具體包括：適應性:與軟件無需采用有別于為該軟件準備的活動或手段就可能適應不同的規定環境有關的

4、軟件屬性易安裝性:與在指定環境下安裝軟件所需努力有關的軟件屬性遵循性:使軟件遵循與可移植性有關的標準或約定的軟件屬性易替換性:與軟件在該軟件環境中用來替代指定的其他軟件的機會和努力有關的軟件屬性基于以上原則，根據項目的不同需求，我們將會考慮采用B/S和C/S兩種模式開發。1、B/S模式B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser）,如NetscapeNavigator或InternetExplorer,月艮務器安裝Oracle、SybaseInformix或SQLServe等數據庫。瀏覽器通過WebServer同數據庫進行數據交互。B/S模式較C/S模式

5、：C/S模式客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部的情況，不是工作量的問題，而是路程的問題。還有，系統軟件升級時，每一臺客戶機需要重新安裝，具維護和升級成本非常高。C/S模式對客戶端的操作系統一般也會有限制，可能適應于Windows系列操作系統，而不適用于Linux、Unix等操作系統。而B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易，只要能上網，再由系統管理員分配一個用戶名和密碼，就可以使用了。甚至可以在線中請

6、，通過公司內部的安全認證(如CA證書)后，不需要人的參與，系統可以自動分配給用戶一個賬號進入系統，這在最大程度上滿足了項目要求。系統采用的是目前較流行的一種Web應用程序開源框架-Struts+Spring+Hibernate(SSH)集成SSH框架的系統從職責上分為四層：表示層、業務邏輯層、數據持久層和域模塊層，以幫助開發人員在短期內搭建結構清晰、可復用性好、維護方便的Web應用程序。其中使用Struts作為系統的整體基礎架構，負責MVC的分離，在Struts框架的模型部分，利用Hibernate框架對持久層提供支持，業務層用Spring支持。具體做法是用面向對象的分析方法根據需求提出一些模

7、型，將這些模型實現為基本的Java對象，然后編寫基本的DAO接口，并給出Hibernate的DAO實現，采用Hibernate架構實現的DAO類來實現Java類與數據庫之間的轉換和訪問，最后由Spring完成業務邏輯。系統的基本業務流程是：在表示層中，首先通過JSP頁面實現交互界面，負責傳送請求(Request和接收響應(Response)然后Struts根據配置文件將ActionServlet接收到的Request委派給相應的Action處理。在業務層中，管理服務組件的SpringloC容器負責向Action提供業務模型（Model）組件和該組件的協作對象數據處理（DAO即件完成業務邏輯，并

8、提供事務處理、緩沖池等容器組件以提升系統性能和保證數據的完整性。而在持久層中，則依賴于Hibernate的對象化映射和數據庫交互，處理DAO組件請求的數據，并返回處理結果。采用上述開發模型，不僅實現了視圖、控制器與模型的徹底分離，而且還實現了業務邏輯層與持久層的分離。這樣無論前端如何變化，模型層只需很少的改動，并且數據庫的變化也不會對前端有所影響，大大提高了系統的可復用性。而且由于不同層之間耦合度小，有利于團隊成員并行工作，大大提高了開發效率的同時，也保證了軟件產品的質量。2、C/S模式C/S（Client/Server;客戶機/服務器）模式又稱C/S結構，是20世紀80年代末逐步成長起來的一

9、種模式，是軟件系統體系結構的一種。C/S結構的關鍵在于功能的分布，一些功能放在前端機（即客戶機）上執行，另一些功能放在后端機（即服務器）上執行。功能的分布在于減少計算機系統的各種瓶頸問題。C/S模式簡單地講就是基于企業內部網絡的應用系統。與B/S（Browser/Server,瀏覽器/服務器）模式相比,C/S模式的應用系統最大的好處是不依賴企業外網環境，即無論企業是否能夠上網，都不影響應用。C/S結構服務器通常采用高性能的PG工作站或小型機，并采用大型數據庫系統，如ORACLESYBASEInfORMix或SQLServer客戶端需要安裝專用的客戶端軟件。C/S結構的優點是能充分發揮客戶端PC

10、的處理能力，很多工作可以在客戶端處理后再提交給服務器，因此對應的優點就是客戶端響應速度快。C/S架構軟件的優勢與劣勢(1)應用服務器運行數據負荷較輕。最簡單的C/S體系結構的數據庫應用由兩部分組成，即客戶應用程序和數據庫服務器程序。二者可分別稱為前臺程序與后臺程序。運行數據庫服務器程序的機器，也稱為應用服務器。一旦服務器程序被啟動，就隨時等待響應客戶程序發來的請求；客戶應用程序運行在用戶自己的電腦上，對應于數據庫服務器，可稱為客戶電腦，當需要對數據庫中的數據進行任何操作時，客戶程序就自動地尋找服務器程序，并向其發出請求，服務器程序根據預定的規則作出應答，送回結果，應用服務器運行數據負荷較輕。(

11、2)數據的儲存管理功能較為透明。在數據庫應用中，數據的儲存管理功能，是由服務器程序和客戶應用程序分別獨立進行的，并且通常把那些不同的(不管是已知還是未知的)前臺應用所不能違反的規則，在服務器程序中集中實現，例如訪問者的權限，編號可以重復、必須有客戶才能建立定單這樣的規則。所有這些，對于工作在前臺程序上的最終用戶，是透明”的，他們無須過問(通常也無法干涉)背后的過程，就可以完成自己的一切工作。在客戶服務器架構的應用中，前臺程序不是非常瘦小”，麻煩的事情都交給了服務器和網絡。在C/S體系的下，數據庫不能真正成為公共、專業化的倉庫，它受到獨立的專門管理。C/S模式系統的開發：C/S結構是建立在中間件

12、產品基礎之上的，要求應用開發者自己去處理事務管理、消息隊列、數據的復制和同步、通信安全等系統級的問題。這對應用開發者提出了較高的要求，而且迫使應用開發者投入很多精力來解決應用程序以外的問題。這使得應用程序的維護、移植和互操作變得復雜。如果客戶端是在不同的操作系統上，C/S結構的軟件需要開發不同版本的客戶端軟件。但是，與B/S結構相比，C/S技術發展歷史更為悠久”。從技術成熟度及軟件設計、開發人員的掌握水平來看，C/S技術應是更成熟、更可靠的。項目總體架構及技術解決方案一、項目總體架構(一)、SSH框架介紹和分析大型企業級Web應用系統的開發通常要求有一個良好的軟件架構、便于協作開發和擴展升級，

13、而傳統的開發模式不能很好地滿足這些要求。基于當前Web應用程序開發面臨的問題，項目結合目前比較流行的開源框架SSH(SpringStruts>Hibernate),具體討論其基本相似性及有關基本概念，提出了一種開發JavaEEWeb用的輕量級解決方案，此系統架構可以在短期內搭建結構清晰、可復用性好、可擴展性好、維護方便的Web應用程序。1、框架技術框架一般具有即插即用的可重用性、成熟的穩定性以及良好的團隊協作性。JavaEES雜的多層結構決定了大型的JavaE頤目需要運用框架和設計模式來控制軟件質量。目前，市場上出現了一些商業的、開源的基于JavaEE勺應用框架，其中主流的框架技術有：基

14、于MVC模式的Struts框架、基于IoC模式的Spring框架以及對象/關系映射框架Hibernate等。2、框架共同點所有現代的網絡開發框架幾乎都遵循了模型-視圖-控制(MVC)設計模式:商業邏輯和描述被分開，由一個邏輯流控制器來協調來自客戶端的請求和服務器上將采取的行動。這條途徑成為了網絡開發的事實上的標準。每個框架的內在的機制當然是不同的，但是開發者們使用來設計和實現他們的Web應用軟件的API是很類似的。差別還存在于每個框架提供的擴展方面，例如標簽庫，JavaBean包裝器等。所有的框架使用不同的技術來協調在Web應用程序之內的導航，例如XML配制文件，java屬性文件或定制屬性。所

15、有的框架在控制器模塊實現的方法方面也存在明顯的不同。例如，EJB可能實例化在每個請求中需要的類或使用Java反射動態地調用一個適當的行為(Action)類。另外,不同框架在各自引入的概念上也有所不同例如，一個框架可能定義用戶請求和反應場所，而另外一個框架可能僅僅定義一個完整的流:從一個請求到多個響答和隨后的再請求。各種Java框架在它們組織數據流的方法方面是很類似的。在請求發出后，在應用程序服務器上產生一些行動；而作為響應，一些可能包含對象集的數據總是被發送到WEB層。然后從那些對象：可能是有setter和getter方法的簡單類、JAVABEANS值對象、或者一些集合對象中提取數據。現代的J

16、ava框架還想方設法簡化開發者的開發任務，如通過使用簡易的APk數據庫連接池、甚至數據庫調用包等提供自動化的追蹤方式來實現。一些框架或者能夠鉤進（hookedinto）另外的JavaEEK術中，例如JMS（Javsffi息服務）或JMX或把這些技術集成到一起。服務器數據持續性和日志也有可能成為框架的一部分。3、MVC模式MVC模式是一個用于將用戶界面邏輯與業務邏輯分離開來的基礎設計模式，它將數據處理、界面以及用戶的行為控制分為：Model（模型）,View（視圖）,Controller（控制器）。Model:負責當前應用的數據獲取與變更及相關的業務邏輯。可用JAVABEANB體現；View:負

17、責顯示信息。可以使用JSPVELOCITY®板等技術；Controller:負責收集轉化用戶的輸入。常用一個SERVLE來實現；View和Controller都依賴于Model,但是Model既不依賴于View,也不依賴于Controller,這是分離的主要優點之一，這樣Model可以單獨的建立和測試以便于代碼復用，View和Controller只需要Model提供數據，它們不會知道、也不會關心數據是存儲在SQLServe還是Oracle數據庫中或者別的什么地方。4、WEB層框架StrutsStruts是一個在JSPModel2基礎上實現的MVC框架，其主要的設計理念是通過控制器將表

18、現邏輯和業務邏輯解耦，以提高系統的可維護性、可擴展性及可重用性。Struts框架的體系結構如下圖所示叫I,曲卜面就上圖所示的體系結構圖分析Struts框架中的MVC組件,視圖(view):視圖部分主要由JSP頁面組成，其中沒有流程邏輯、業務邏輯和模型信息，只有標記。Struts自身包含了一組標記庫(TagLib),這也是Struts的精華之一，靈活運用它們可以簡化JSP頁面的代碼，提高開發效率。，控制器(controller):Struts中的Controller主要是其自身提供的ActionServletoActionServlet接收所有來自客戶端的請求并根據配置文件中的定義將控制轉移到適

19、當的Action對象。，模型(model):Struts沒有定義具體Model層的實現，Model層通常是和業務邏輯緊密相關的，有持續化的要求。目前在商業領域和開源世界，都有一些優秀的工具可以為Model層的開發提供便利、業務邏輯層框架Spring5Spring是一個解決了許多JavaEEF發中常見問題并能夠替代EJ咖術的強大的輕量級框架。這里所說的輕量級指的是Spring框架本身，而不是指Spring只能用于輕量級的應用開發。Spring的輕盈體現在其框架本身的基礎結構以及對其他應用工具的支持和裝配能力。與EJB這種龐然大物相比，Spring可使程序研發人員把各個技術層次之間的風險降低。Sp

20、ring框架的核心是控制翻轉IoC（InversionofControl）/依賴注入DI（DependenceInjection）機制。IoC是指由容器中控制組件之間的關系（這里，容器是指為組件提供特定服務和技術支持的一個標準化的運行時的環境）而非傳統實現中由程序代碼直接操控，這種將控制權由程序代碼到外部容器的轉移，稱為翻轉”。DI是對IoC更形象的解釋，即由容器在運行期間動態地將依賴關系（如構造參數、構造對象或接口）注入到組件之中。Spring采用設值注入（使用Setter方法實現依賴）和構造子注入（在構造方法中實現依賴）的機制，通過配置文件管理組建的協作對象，創建可以構造組件的IoC容器。

21、這樣，不需要編寫工廠模式、單例模式或者其他構造的方法，就可以通過容器直接獲取所需的業務組件。Spring框架的結構如下圖所示。Il|n）汨.注樞呈出發地或Spring框架由七個定義明確的模塊組成，且每個模塊或組件都可以單獨存在，或者與其他一個或多個模塊聯合實現。SpringCoreContainer是一個用來管理業務組件的IoC容器，是Spring應用的核心；SpringDAO和SpringORM不僅提供數據訪問的抽象模塊，還集成了對Hibernate、JDO和iBatis等流行的對象關系映射框架的支持模塊，并且提供了緩沖連接池、事務處理等重要的服務功能，保證了系統的性能和數據的完整性；Spr

22、nigWeb模塊提供了Web應用的一些抽象封裝，可以將Struts、Webwork等Web框架與Spring整合成為適用于自己的解決方案。Spring框架可以成為企業級應用程序一站式的解決方案，同時它也是模塊化的框架，允許開發人員自由地挑選適合自己應用的模塊進行開發。Spring框架式是一個松耦合的框架，框架的部分耦合度被設計為最小，在各個層次上具體選用哪個框架取決于開發者的需要。6、持久層框架HibernateO/Rmapping技術是為了解決關系型數據庫和面向對象的程序設計之間不匹配的矛盾而產生的。Hibernate是目前最為流行的O/Rmapping框架，它也是開源軟件,它在關系型數據庫

23、和Java對象之間做了一個自動映射，使得程序員可以以非常簡單的方式實現對數據庫的操作，它不僅負責從Java類到數據庫表格（以及來自Java數據類型的SQL數據類型）的映射，而且還提供數據查詢和檢索能力，并能大大減少花在SQL和JDBC手工數據處理上的開發時間。Hibernate工作原理如下圖所示應用強庠掙&眥青豆作II口材七件Hibernate通過對JDBC的封裝，向程序員屏蔽了底層的數據庫操作，使程序員專注于OO程序的開發，有助于提高開發效率。程序員訪問數據庫所需要做的就是為持久化對象編制xml映射文件。底層數據庫的改變只需要簡單地更改初始化配置文件或者即可，不會對應用程序產生影響H

24、ibernate有自己的面向對象的查詢語言HQL,HQL功能強大，支持目前大部分主流的數據庫，如Oracle、DB2、MySQLMicrosoftSQLServe咻，是目前應用最廣泛的O/R映射工具。Hibernate為快速開發應用程序提供了底層的支持。（二卜基于SSHff架的Web應用架構分析與設計前面分析了基于JavaEE勺SSH框架技術，現代的企業開發中，越來越多地引入了多層架構設計模式。SSH就是其中之一，SSHg構是當前主流的架構，在很多領域，包括金融、電信項目，大型門戶網站均選擇該架構作為業務支撐架構，開發流程也已經非常成熟。但是該結構開發起來，依舊存在一些問題。分析這些問題，得先

25、從SSH架構的組成說起。SSH為Struts+Spring+Hibernate的組成方式，Struts實現MVC,Spring負責架構的結合，Hibernate進行數據的持久化。通常其分層開發的結構圖如下illgETwtfyr呼文件和欣捌熱陰泰學史初4”這樣的結構，系統從職責上分為四層：WEB層、業務邏輯層、數據持久層和實體層。其中使用Struts作為系統的整體基礎架構，負責MVC的分離，在Struts框架的模型部分，利用Hibernate框架對持久層提供支持，業務層用Spring支持。具體做法是用面向對象的分析方法根據需求提出一些模型，將這些模型實現為基本的Java對象，然后編寫基本的DAO

26、接口，并給出Hibernate的DAO實現，采用Hibernate架構實現的DAO類來實現Java類與數據庫之間的轉換和訪問，最后由Spring完成業務邏輯。系統的基本業務流程是：在WEB表示層中，首先通過JSP頁面實現交互界面，負責傳送請求（Request和接收響應（Response）然后Struts根據配置文件將ActionServlet接收到的Request委派給相應的Action處理。在業務層中，管理服務組件的SpringIoC容器負責向Action提供業務模型（Model）組件和該組件的協作對象數據處理（DAO）fi件完成業務邏輯，并提供事務處理、緩沖池等容器組件以提升系統性能和保證

27、數據的完整性。而在持久層中，則依賴于Hibernate的對象化映射和數據庫交互，處理DAO組件請求的數據，并返回處理結果。采用上述開發模型，不僅實現了視圖、控制器與模型的徹底分離，而且還實現了業務邏輯層與持久層的分離。這樣無論前端如何變化，模型層只需很少的改動，并且數據庫的變化也不會對前端有所影響，大大提高了系統的可復用性。而且由于不同層之間耦合度小，有利于團隊成員并行工作，大大提高了開發效率。但是對于當前日益復雜化的的開發，卻存在不少問題，歸納起來主要有以下的不足：,DAO和服務層容易出現職責不明，由于按照MVC邏輯，業務代碼應該寫在StrutsAction里，但是其事務的提供，卻是配置在S

28、ervice層。為了一組在邏輯上完整的數據操作業務邏輯，需要涉及兩個層（ServiceAction）來進行編寫，遇到判斷的情況下，為了保證完整的事務操作，則需要將業務代碼移到Service層完成，而通常習慣了在StrutsAction里調用多次Service而產生多個事務，但在出現Exception導致出錯時，操作之前調用的Service事務的業務數據沒有被回滾。，當需要返回的數據供AJAX使用，操作JSONEXML的大量使用時。開發起來會很費力，一段同樣的業務代碼，為了使用AJAX和XML可能需要重新編寫一次，或者在同一個ACTION里通過標志來判斷，對分層結構造成了比較糟糕的破壞。如果設計

29、得不好，為了使用JSONffiXML還得額外增加大量的配置，嚴重降低了開發效率。因此，為了克服這些缺點，對于SSH架構，進行了重新的分層，共享了業務代碼。簡化了開發、增強了與AJAX技術、XML技術的結合。提供了一種更高效的開發模式。其開發的結構圖如下：MQ口E1蝙寫業務邏st旭異常，漏圉DAO迸行9爨廉作實現BusmcssSonricc插口并配宜到前面官根攔相俳霜F兇吞豈.1<要的方,主并配置到Sprinc方法.確定對邪肺對去SERVICE層!DAOp海曲需相寫Form并設置琳應的AciiotiPath,畫面調用對雙的ActionU非MFYCAO空分析而要常規提交的操作,編寫而施的Fc

30、rw用于；年懦懶交則fi示ReM“BUS異步提交則解析Jstm：質也數據并顯示,|.一魄嘏町胸鬢分析stihnut提交的確作及分析需要的白缶且力捍手卬洋這個架構的優點在于，由于業務代碼統一實現BusinessServicdil口，使得只需要相對固定的幾個StrutsAction類調用Service層的方法，便可以完成工作。包括JSONS式輸出，XML輸出及WebService輸出均調用Service層方法來完成功能。這樣便實現了業務代碼的分離，以及與前端框架的極大解耦。二、技術解決方案開發一款好的軟件產品，離不開一個好的開發過程。開發期間對過程的把控程度，往往會決定軟件產品的質量好壞。因此，開

31、發前期的計劃流程是必不可少的。本公司軟件系統的開發是按階段進行的，一般劃分為以下階段項目可行性分析可行性研究報告需求分析軟件需求說明書概要設計概要設計說明書»詳細設計數據庫設計說明書編碼詳細設計說明書測試測試計劃修改完善測試分析報告»驗收驗收報告維護用戶操作手冊1、可行性分析可行性分析的目的是明確系統的目的、功能和要求，了解目前所具備的開發環境和條件，分析的內容有：在技術能力上是否可以支持在經濟上效益如何在法律上是否符合要求與部門、企業的經營和發展是否吻合系統投入運行后的維護有無保障可行性討論的目的是判定軟件系統的開發有無價值，分析和討論的內容形成系統開發計劃書”，主要內容

32、有：(1)開發的目的及所期待的效果(2)系統的基本設想，涉及的業務對象和范圍(3)開發進度表，開發組織結構（4）開發、運行的費用（5）預期的系統效益（6）開發過程中可能遇到的問題及注意事項。2、需求分析需求分析是軟件系統開發中最重要的一個階段，直接決定著系統的開發質量和成敗。因此必須要明確用戶的要求和應用現場環境的特點，了解系統應具有哪些功能、數據的流程和數據之間的聯系。需求分析應有用戶參加，到使用現場進行調研學習，軟件設計人員應虛心向技術人員和使用人員請教，共同討論解決需求問題的方法，對調查結果進行分析，明確問題的所在。需求分析階段的工作，可以分為四個方面：問題識別，分析與綜合，制訂規格說明

33、，評審。（一）、問題識別從系統角度來理解軟件，確定對所開發系統的綜合要求，并提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求（做什么），性能需求（要達到什么指標），環境需求（如機型，操作系統等），可靠性需求（不發生故障的概率），安全保密需求,用戶界面需求，資源使用需求（軟件運行是所需的內存，CPU等），軟件成本消耗與開發進度需求，預先估計以后系統可能達到的目標。（二卜分析與綜合逐步細化所有的軟件功能，找出系統各元素間的聯系，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最后，綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型（做什么的模型）

34、。（三卜制訂規格說明書即編制文檔，描述需求的文檔稱為軟件需求規格說明書。（四）、評審對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作，否則重新進行需求分析。需求分析的內容最終會編寫成系統需求分析報告”。3.系統設計（一）、設計原則和設計要求描述對本軟件系統進行概要設計的原則，通常可以考慮以下幾方面的內容：1、命名規則；2、模塊獨立性原則；3、邊界設計原則；4、數據庫設計規則；5、必須的安全措施；6、安全性和保密原則；7、系統靈活性要求；8、系統易操作性要求；9、系統可維護性要求；（二卜系統邏輯設計系統邏輯設計主要是根據軟件產品需求規格說明書和軟件產品數據字典

35、建立系統的邏輯模型。此種模型暫時與系統的物理因素（例如:計算機、數據庫管理系統）無關。它是系統需求與物理實現的中間結構，它的主要結果是建立：系統結構圖、系統界面結構圖、系統出錯處理、以及系統開發技術說明。（三卜系統組織設計系統組織設計通過系統組織表描述本系統由哪些子系統（模塊）組成，這些子系統與業務職能之間的關系，以及各個子系統的安裝地點。系統組織表的格式如下子系統編號英文名稱中文名稱業務職能安裝地點備注其中：1、子系統編號給出本系統中指定子系統的順序編號。如果本系統末劃分為多個子系統，僅由一個運行模塊組成；則本項內容仍需要描述，但是本表內容只有一行。在一個系統中有可能安裝若干個相同的子系統，

36、在這種情況下，應該視為一個子系統，并且對多個安裝地點分別進行描述。如果相同的子系統通過系統設置，實現的業務職能具有明顯差異時，應該采用多行進行分別描述，并且在備注中說明其差異所在。2、子系統英文名稱給出本子系統的英文名稱，該名稱是在應用軟件中實際使用的可執行文件名稱，必須能夠說明該子系統的特點。若本系統中只有一個子系統，則本項內容仍需要描述，但是本表內容只有一行。3、子系統中文名稱給出本子系統的中文名稱，該名稱必須能夠說明該子系統的特點。若本系統中只有一個子系統，則本項內容仍需要描述，但是本表內容只有一行。4、業務職能描述該子系統完成的核心業務。5、安裝地點描述該子系統實際安裝的部門、或者某個

37、具體地點。6、備注針對該子系統，需要說明的其它有關問題。（四卜系統結構設計1、系統特性表系統特性是系統中完成某項具體操作的基本單元，它由入口參數，出口參數以及處理過程三部分組成。系統特性可以具有操作界面，也可以沒有操作界面；可以被其它操作界面、或者系統特性調用，也可以調用其它操作界面、非操作界面、或者系統特性；但是不允許遞歸調用（調用自己），包括間接遞歸調用。當系統由多個子系統（模塊）組成時，每個子系統分別使用一張系統特性表進行描述。系統特性表的格式如下：子系統編號：子系統英文名稱：子系統中文名稱：特性編號系統特征系統特征操作功能調用對象被調用對象備注英文名稱中文名稱說明：其中：（1）、子系統

38、編號含義同上。（2）、子系統英文名稱含義同上。(3)、子系統中文名稱含義同上。(4)、特性編號整個系統所有特性的統一編號。(5)、系統特性英文名稱系統特性的英文正式名稱，將來用于軟件開發中，必須符合命名規范。(6)、系統特性中文名稱系統特性的中文正式名稱，來源于需求規格說明書中，系統特性一節中的有關描述。(7)、操作功能是指該特性實際完成的操作說明。(8)、調用對象是指調用該系統特性的系統對象，這里的系統對象可以是系統特性、也可以是操作界面。(9)、被調用對象是指被該系統特性調用的系統對象，這里的系統對象可以是系統特性、也可以是操作界面。(10)、備注描述與該系統特性有關的其它注意事項。(11

39、)、說明描述與該系統特性表有關的其它注意事項。(五卜系統接口設計1、系統接口表接口作為系統的一種輸入，輸出形式，分為網絡接口、數據庫接口、RS-232申行485申行總線接口、并行I/O接口等等多種類型。訊接口、IEEI當系統由多個子系統(模塊)組成時，每個子系統分別使用一張系統接口表進行描述。系統接口表的格式如下：子系統編號子系統英文名稱子系統中文名稱接口編號接口名稱接口類型接口性質接口速率接口協議備注說明：其中：(1)、子系統編號含義同上。(2)、子系統英文名稱含義同上。(3)、子系統中文名稱含義同上。(4)、接口編號整個系統所有接口的統一編號。(5)、接口名稱系統接口的正式名稱，必須符合通

40、常習慣。(6)、接口類型指出該接口所傳輸的數據在該模塊中起到的作用。(7)、接口性質指出該接口在通訊中起到的作用，這里的作用可以是：輸入、輸出、雙向。指出該接口的傳輸速率。如果該接口依賴于其它通訊方式，那么傳輸速率將不它所依賴的其它通訊方式的速率。(9)、接口協議給出該接口實際使用的通訊協議。10)、相關對象(給出直接使用本接口的系統對象，這里的系統對象，可以是操作界面，也可以是系統特性。(11)、備注描述與該系統接口有關的其它注意事項。(12)、說明描述與該系統接口表有關的其它注意事項。(六卜系統完整性設計描述系統對象(數據元、數據類)，所受到的邏輯約束關系。當系統由多個子系統(模塊)組成時

41、，每個子系統應分別使用一張系統完整性約束表進行描述。系統完整性約束表的格式如下：子系統編號子系統英文名稱子系統中文名稱約束編號完整性名稱相對對象名約束表達式備注說明：其中：含義同上（2）、子系統英文名稱含義同上。（3）、子系統中文名稱含義同上。（4）、約束編號整個系統所有約束的統一編號。（5）、完整性名稱系統完整性約束的正式名稱，必須符合通常習慣。6）、相對對象名（完整性約束中的相關對象（數據元和數據類）。7）、約束表達式（用一階邏輯表達式表達的約束方程式。（8）、備注描述與該系統完整性約束有關的其它注意事項。（9）、說明描述與該系統完整性約束表有關的其它注意事項。系統設計具體可根據系統的規模

42、分成概要設計和詳細設計兩個階段，概要設計包括：劃分系統模塊每個模塊的功能確定用戶使用界面概要設計輸入輸出數據的概要設計報表概要設計數據之間的聯系、流程分析文件和數據庫表的邏輯設計硬件、軟件開發平臺的確定有規律數據的規范化及數據惟一性要求。系統的詳細設計是對系統的概要設計進一步具體化，其主要工作有：文件和數據庫的物理設計輸入輸出記錄的方案設計對各子系統的處理方式和處理內容進行細化設計編制程序設計任務書。程序說明書通常包括程序規范、功能說明、程序結構圖，通常用HPIPO(HierarchyPlusInputProcessOutpu胤描述。4、編碼根據程序設計任務書的要求，用計算機算法語言實現解題的

43、步驟，主要工作包括：模塊的理解和進一步劃分以模塊為單位的邏輯設計，也就是模塊內的流程圖的編制編寫代碼，用程序設計語言編制程序進行模塊內功能的測試、單元測試。程序質量的要求包括：滿足要求的確切功能處理效率高操作方便，用戶界面友好程序代碼的可讀性好，函數、變量標識符合規范擴充性、維護性好。降低程序的復雜性也是十分重要的，系統的復雜性由模塊間的接口數來衡量，一般地講，n個模塊的接口數的最大值為n(n-1)若是層次結構，n個模塊的接口數的最小值為n-1o為使復雜性最小，對模塊的劃分設計常常采用層次結構。要注意編制的程序或模塊應容易理解、容易修改，模塊應相互獨立，對某一模塊的修改應對其他模塊的功能不產生

44、影響，模塊間的聯系盡可能少。5.系統測試測試是為了發現程序中的錯誤，對于設計的軟件，出現錯誤是難免的。系統測試通常由經驗豐富的設計人員設計測試方案和測試樣品，并寫出測試過程的詳細報告。系統測試是在單元測試的基礎上進行的，包括：測試方案的設計；進行測試；寫出測試報告；用戶對測試結果進行評價。具體測試方式如下：1 .黑盒測試黑盒測試也稱為功能測試，它著眼于程序的外部特征，而不考慮程序的內部邏輯結構。測試者把被測程序看成一個黑盒，不用關心程序的內部結構。黑盒測試是在程序接口處進行測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數據產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性

45、。黑盒測試是基于用戶角度進行的測試。2 .白盒測試本公司系統軟件測試的主要方法之一，也稱結構測試、邏輯驅動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內部結構、算法等信息，這是從程序設計者的角度對程序進行的測試。它的優點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。3 .灰盒測試可以理解為靜態的白盒測試或動態的黑盒測試，灰盒就是界于黑白之間，對軟件內部有所了解，但不見得到了如指掌的程度，卻可以結合這些了解做些比黑盒多點的測試。4 .文檔測試文檔測試涵蓋面很大，在軟件的各個版本中均有所使用。隨著軟件版本的變化，文檔測試的測試內容也有所變化。在需求分析以及原

46、型架構階段，文檔測試主要目標是：Sitemaps動作分解列表、數據庫ER圖、UML用例圖、流程圖、需求文檔等文檔。文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內容前后矛盾。完整性是指文檔不可以漏掉關鍵性內容。可理解性是指在文檔中描述的語言要簡明易懂，不能讓別的開發人員拿到文檔時看不懂文檔的內容。5 .命名規范測試命名規范測試用于測試項目中的文件命名、代碼以及版本號等書寫是否符合規范。6 .需求完整性測試需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認需求是否明確。另外，需求完整

47、性測試也承擔著一部分澄清需求的任務。7 .鏈接完整性測試在原型架構階段，鏈接完整性的測試是非常有必要的。該項測試任務主要是檢查假頁面中各種鏈接是否完整，是否指向目標位置，屬于檢查性的測試。8 .頁面完整性測試頁面完整性測試主要存在于集成測試階段以及其后續其它階段中，測試頁面是否完整，頁面質量是否達標，屬于檢查性測試。9 .UI合理性測試UI合理性測試也就是人機交互界面的合理性，UI合理性測試的內容很多，具體測試內容如下：o提示、菜單、幫助的格式是否一致；。提示、菜單、幫助中的術語是否一致；o各個控件之間的對齊方式是否一致；。輸入界面和輸出界面在外觀、布局、交互方式上是否一致；。功能類似的相關界

48、面在外觀、布局、交互方式上是否一致；o同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小是否與界面的大小比例協調；o多個連續界面依次出現的情況下，界面的外觀、操作方式是否一致；o系統是否拒絕客戶的錯誤輸入并做出提示；o系統是否在用戶完成操作時給出操作成功的提示；。用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差；o各個控件的間隔是否一致，垂直和水平方向上是否對齊；。是否允許動作的可逆性，返回原有操做；10 .數據和數據庫完整性測試在開發階段開發人員隨時都有可能根據需要來修改數據庫，所以對數據和數據庫完整性測試在軟

49、件項目的任何階段也是非常必要的。該項測試內容主要是以數據庫表為單位，檢查數據庫表以及表中各字段命名是否符合命名規范，表中字段是否完整，數據庫表中的字段描述是否正確包括字段的類型、長度、是否為空，數據庫表中的關系、索引、主鍵、約束是否正確。11 .功能測試功能測試在軟件項目的任何階段中都是重要的。實現功能，滿足客戶需求是軟件本身最大的使命。功能測試在任何階段下基本上都作為測試工作的第一項出現。該項測試任務主要為了測試已實現的功能是否滿足需求，是否正確，是否有價值以及是否完整。在黑盒和白盒測試狀態下，該測試均會被使用。功能測試中測試人員往往會忽略掉一些細節問題，比如：一個功能的實現必須要經過6步操

50、作才能完成，而且需要加入20條信息才能看得出測試結果，有的測試人員為了節省時間雖然做完了6步操作，但是沒有加入足量的信息，使得測試不全面，正是因為這樣而導致一些隱藏的BUG沒有被測試出來。所以說在功能測試中要按部就班的把所有要進行的測試功能每一步都執行一遍，應該添加的數據都添加完整，以避免遺漏掉BUG沒有測試出來。12.壓力測試壓力測試是為了發現在什么條件下您的應用程序的性能會變得不可接受。這通過改變應用程序的輸入以對應用程序施加越來越大的負載并測量在這些不同的輸入時性能的改變來實現的。這種操作也稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試一一增加用戶數量以對應用程序進行壓力測試。

51、對應用程序進行壓力測試最簡單的方法是手工改變輸入（客戶機數量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內改變輸入，那么你可以借助一個自動化的壓力測試工具來完成此測試。13 .安全性測試安全性測試主要是測試系統在沒有授權的內部或者外部用戶對系統進行攻擊或者惡意破壞時如何進行處理，是否仍能保證數據和頁面的安全。測試人員可以學習一些黑客技術，來對系統進行攻擊。另外，對操作權限的測試也包含在安全性測試中。具體測試內容如下：。執行添加、刪除、修改等動作中是否做過登錄檢測。o退出系統之后的操作是否可以完成o所有插入表單操作中輸入特殊字符是否可以正常

52、輸正常存儲，特殊字符為:#,%,*()-+=、|;:'"?/<>,。o在帶有參數的回顯數據的動作中更改參數，把參數改為特殊字符并加入操作語句看是否出錯。測試表單中有沒有做標簽檢測，標簽檢測是否完整。o在插入表單中加入特殊的HTML代碼，例如：<marquee>表單中的字本是否移動,</marquee>。14 .頁面腳本測試頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進行測試。其主要內容包括：相關頁面中的腳本是否正常運行，JavaScript腳本是否有錯誤頁面。15 .提示文本測試提示文本測試從嚴格意義上來

53、講應該屬于UI合理性測試的一部分，該項測試主要針對各個頁面中使用到的大量提示文檔進行測試，主要包括：表達不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。16 .瀏覽器測試由于B/S結構項目是基于瀏覽器運行的，所以需要對瀏覽器進行必要的測試。該測試任務主要是軟件對各種瀏覽器、FireFox瀏覽器)的支持是否正常，在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。17 .安裝測試在軟件項目的后期階段，會對做好的軟件進行打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進行安裝功能方面的測試。該測試的主要任務是檢查軟件是否能夠正常

54、安裝使用、是否可以完全卸載此軟件的所有功能和頁面。6、文檔資料文檔包括開發過程中的所有技術資料以及用戶所需的文檔，軟件系統的文檔一般可分為系統文檔和用戶文檔兩類。用戶文檔主要描述系統功能和使用方法，并不考慮這些功能是怎樣實現的，系統文檔描述系統設計、實現和測試等方面的內容。文檔是影響軟件可維護性、可用性的決定因素，有句話講，系統編程人員的每一張紙片都要保留，所以文檔的編制是軟件開發過程中的一項重要工作。系統文檔包括：開發軟件系統在計劃需求分析設計編制調試運行等階段的有關文檔。在對軟件系統進行修改時，系統文檔應同步更新，并注明修改者和修改日期，如有必要應注明修改原因，應切記過時的文檔是無用的文檔

55、。用戶文檔包括：系統功能描述安裝文檔，說明系統安裝步驟以及系統的硬件配置方法用戶使用手冊，說明使用軟件系統方法和要求，疑難問題解答參考手冊，描述可以使用的所有系統設施，解釋系統出錯信息的含義及解決途7、系統的運行與維護系統只有投入運行后，才能進一步對系統檢驗，發現潛在的問題，為了適應環境的變化和用戶要求的改變，可能會對系統的功能、使用界面進行修改。要對每次發現的問題和修改內容建立系統維護文檔，并使系統文檔資料同步更新。服務保證措施本公司軟件質量保證由各項任務構成，這些任務的參與者有兩種人：軟件開發人員和質量保證人員。前者負責技術工作，后者負責質量保證的計劃、監督、記錄、分析及報告工作。軟件開發

56、人員通過采用可靠的技術方法和措施，進行正式的技術評審，執行計劃周密的軟件測試來保證軟件產品的質量。軟件質量保證人員則輔助軟件開發組得到高質量的最終產品。我們的軟件質量保證計劃大體分為如下三大部分：把軟件研制合理地劃分為若干階段，并針對每個階段的特點，制定出質量評審、評測的要求和措施。從軟件質量的要求出發，制定出相應的技術和管理規范，如軟件文檔規范、軟件編程規范、軟件測試規范、軟件版本控制規范等。創建和積累公用模塊，向軟件工廠化方向發展。1、軟件研制的階段劃分及其質量控制我們把軟件系統的研制劃分為8個階段，即總體需求分析、總體設計、各分系統的需求說明及概要設計、詳細設計（面向子系統）、程序編制、自測試、組裝與驗收測試、試用和初步定型。我們規定，總體需求分析及總體設計需經有關領導及管理專家評審認定。分系統的需求說明、概要設計及詳細設計需經總工程師組織的技術評審組評審。評審前，多數分系統的需求說明及概要設計需經有代表性的用戶審核認可，即分析和設計階段主要靠評審把關，編程和實施階段主要靠執行規范和測試把關。每次評審的結果都有相應的記錄，并填寫相應的表格。2、軟件的文檔規范系統開發的文檔要求是：每個分系統必須有需求說明、概要設計，每個子系統必須有詳細設計和操作使用說明。需求說明、概要設計和詳細設計必須用行完成，而且規定，詳細設計未經評審通過不能