軟件項目招投標文件技術標書最全最詳細

1、.12.4.2供應商針對本項目技術服務類總體要求的理解在軟件開發(fā)的過程中,我們一向遵循軟件產(chǎn)品的以下原則：1、功能性:與一組功能及其指定的性質(zhì)有關的一組屬性,具體包括：適合性:與規(guī)定任務能否提供一組功能以及這組功能的適合程度有關的軟件屬性準確性:與能否得到正確或相符的結果或效果有關的軟件屬性互用性:與同其他指定系統(tǒng)進行交互的能力有關的軟件屬性依從性:使軟件遵循有關的標準,約定,法規(guī)及類似規(guī)定的軟件屬性安全性:與防止對程序及數(shù)據(jù)的非授權的故意或意外訪問的能力有關的軟件屬性2、可靠性:與在規(guī)定的一段時間和條件下,軟件維持其性能水平的能力有關的一組屬性,具體包括：成熟性:與由軟件故障引起失效的頻度有

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

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

4、指定環(huán)境下安裝軟件所需努力有關的軟件屬性遵循性:使軟件遵循與可移植性有關的標準或約定的軟件屬性易替換性:與軟件在該軟件環(huán)境中用來替代指定的其他軟件的機會和努力有關的軟件屬性基于以上原則,根據(jù)項目的不同需求,我們將會考慮采用B/S和C/S兩種模式開發(fā)。1、B/S模式B/S是Brower/Server的縮寫,客戶機上只要安裝一個瀏覽器Browser,如Netscape Navigator或Internet Explorer,服務器安裝Oracle、Sybase、Informix或 SQL Server等數(shù)據(jù)庫。瀏覽器通過Web Server 同數(shù)據(jù)庫進行數(shù)據(jù)交互。B/S模式較C/S模式：C/S模式

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

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

7、型實現(xiàn)為基本的Java對象,然后編寫基本的DAO接口,并給出Hibernate的DAO實現(xiàn),采用Hibernate架構實現(xiàn)的DAO類來實現(xiàn)Java類與數(shù)據(jù)庫之間的轉換和訪問,最后由Spring完成業(yè)務邏輯。 系統(tǒng)的基本業(yè)務流程是： 在表示層中,首先通過JSP頁面實現(xiàn)交互界面,負責傳送請求和接收響應,然后Struts根據(jù)配置文件將ActionServlet接收到的Request委派給相應的Action處理。在業(yè)務層中,管理服務組件的Spring IoC容器負責向Action提供業(yè)務模型組件和該組件的協(xié)作對象數(shù)據(jù)處理組件完成業(yè)務邏輯,并提供事務處理、緩沖池等容器組件以提升系統(tǒng)性能和保證數(shù)據(jù)的完整性

8、。而在持久層中,則依賴于Hibernate的對象化映射和數(shù)據(jù)庫交互,處理DAO組件請求的數(shù)據(jù),并返回處理結果。 采用上述開發(fā)模型,不僅實現(xiàn)了視圖、控制器與模型的徹底分離,而且還實現(xiàn)了業(yè)務邏輯層與持久層的分離。這樣無論前端如何變化,模型層只需很少的改動,并且數(shù)據(jù)庫的變化也不會對前端有所影響,大大提高了系統(tǒng)的可復用性。而且由于不同層之間耦合度小,有利于團隊成員并行工作,大大提高了開發(fā)效率的同時,也保證了軟件產(chǎn)品的質(zhì)量。2、C/S模式C/S Client/Server,客戶機/服務器模式又稱C/S結構,是20世紀80年代末逐步成長起來的一種模式,是軟件系統(tǒng)體系結構的一種。C/S結構的關鍵在于功能的分

9、布,一些功能放在前端機即客戶機上執(zhí)行,另一些功能放在后端機即服務器上執(zhí)行。功能的分布在于減少計算機系統(tǒng)的各種瓶頸問題。C/S模式簡單地講就是基于企業(yè)內(nèi)部網(wǎng)絡的應用系統(tǒng)。與B/SBrowser/Server,瀏覽器/服務器模式相比,C/S模式的應用系統(tǒng)最大的好處是不依賴企業(yè)外網(wǎng)環(huán)境,即無論企業(yè)是否能夠上網(wǎng),都不影響應用。 C/S結構服務器通常采用高性能的PC、工作站或小型機,并采用大型數(shù)據(jù)庫系統(tǒng),如ORACLE、SYBASE、InfORMix或 SQL Server。客戶端需要安裝專用的客戶端軟件。 C/S結構的優(yōu)點是能充分發(fā)揮客戶端PC的處理能力,很多工作可以在客戶端處理后再提交給服務器,因此

10、對應的優(yōu)點就是客戶端響應速度快。C/S架構軟件的優(yōu)勢與劣勢：1應用服務器運行數(shù)據(jù)負荷較輕。最簡單的C/S體系結構的數(shù)據(jù)庫應用由兩部分組成,即客戶應用程序和數(shù)據(jù)庫服務器程序。二者可分別稱為前臺程序與后臺程序。運行數(shù)據(jù)庫服務器程序的機器,也稱為應用服務器。一旦服務器程序被啟動,就隨時等待響應客戶程序發(fā)來的請求；客戶應用程序運行在用戶自己的電腦上,對應于數(shù)據(jù)庫服務器,可稱為客戶電腦,當需要對數(shù)據(jù)庫中的數(shù)據(jù)進行任何操作時,客戶程序就自動地尋找服務器程序,并向其發(fā)出請求,服務器程序根據(jù)預定的規(guī)則作出應答,送回結果,應用服務器運行數(shù)據(jù)負荷較輕。2數(shù)據(jù)的儲存管理功能較為透明。在數(shù)據(jù)庫應用中,數(shù)據(jù)的儲存管理功

11、能,是由服務器程序和客戶應用程序分別獨立進行的,并且通常把那些不同的不管是已知還是未知的前臺應用所不能違反的規(guī)則,在服務器程序中集中實現(xiàn),例如訪問者的權限,編號可以重復、必須有客戶才能建立定單這樣的規(guī)則。所有這些,對于工作在前臺程序上的最終用戶,是透明的,他們無須過問通常也無法干涉背后的過程,就可以完成自己的一切工作。在客戶服務器架構的應用中,前臺程序不是非常瘦小,麻煩的事情都交給了服務器和網(wǎng)絡。在C/S體系的下,數(shù)據(jù)庫不能真正成為公共、專業(yè)化的倉庫,它受到獨立的專門管理。C/S模式系統(tǒng)的開發(fā)：C/S結構是建立在中間件產(chǎn)品基礎之上的,要求應用開發(fā)者自己去處理事務管理、消息隊列、數(shù)據(jù)的復制和同步

12、、通信安全等系統(tǒng)級的問題。這對應 用開發(fā)者提出了較高的要求,而且迫使應用開發(fā)者投入很多精力來解決應用程序以外的問題。這使得應用程序的維護、移植和互操作變得復雜。如果客戶端是在不同的操作系統(tǒng)上,C/S結構的軟件需要開發(fā)不同版本的客戶端軟件。但是,與B/S結構相比,C/S技術發(fā)展歷史更為悠久。從技術成熟度及軟件設計、開發(fā) 人員的掌握水平來看,C/S技術應是更成熟、更可靠的。12.4.3 項目總體架構及技術解決方案一、項目總體架構一、SSH框架介紹和分析大型企業(yè)級Web應用系統(tǒng)的開發(fā)通常要求有一個良好的軟件架構、便于協(xié)作開發(fā)和擴展升級,而傳統(tǒng)的開發(fā)模式不能很好地滿足這些要求?；诋斍癢eb應用程序開

13、發(fā)面臨的問題,項目結合目前比較流行的開源框架SSHSpring、Struts、Hibernate,具體討論其基本相似性及有關基本概念,提出了一種開發(fā)JavaEE Web應用的輕量級解決方案,此系統(tǒng)架構可以在短期內(nèi)搭建結構清晰、可復用性好、可擴展性好、維護方便的Web應用程序。1、框架技術框架一般具有即插即用的可重用性、成熟的穩(wěn)定性以及良好的團隊協(xié)作性。JavaEE復雜的多層結構決定了大型的JavaEE項目需要運用框架和設計模式來控制軟件質(zhì)量。目前,市場上出現(xiàn)了一些商業(yè)的、開源的基于JavaEE的應用框架,其中主流的框架技術有：基于MVC模式的Struts框架、基于IoC模式的Spring框架以

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

15、每個請求中需要的類或使用Java反射動態(tài)地調(diào)用一個適當?shù)男袨锳ction類。另外,不同框架在各自引入的概念上也有所不同。例如,一個框架可能定義用戶請求和反應場所,而另外一個框架可能僅僅定義一個完整的流：從一個請求到多個響答和隨后的再請求。各種Java框架在它們組織數(shù)據(jù)流的方法方面是很類似的。在請求發(fā)出后,在應用程序服務器上產(chǎn)生一些行動；而作為響應,一些可能包含對象集的數(shù)據(jù)總是被發(fā)送到WEB層。然后從那些對象：可能是有setter和getter方法的簡單類、JAVABEANS、值對象、或者一些集合對象中提取數(shù)據(jù)。現(xiàn)代的Java框架還想方設法簡化開發(fā)者的開發(fā)任務,如通過使用簡易的API、數(shù)據(jù)庫連接

16、池、甚至數(shù)據(jù)庫調(diào)用包等提供自動化的追蹤方式來實現(xiàn)。一些框架或者能夠鉤進hooked into另外的JavaEE技術中,例如JMS或JMX,或把這些技術集成到一起。服務器數(shù)據(jù)持續(xù)性和日志也有可能成為框架的一部分。 3、MVC模式MVC模式是一個用于將用戶界面邏輯與業(yè)務邏輯分離開來的基礎設計模式,它將數(shù)據(jù)處理、界面以及用戶的行為控制分為：Model模型View視圖Controller控制器。 Model：負責當前應用的數(shù)據(jù)獲取與變更及相關的業(yè)務邏輯。可用JAVABEAN來體現(xiàn)； View：負責顯示信息?？梢允褂肑SP、VELOCITY模板等技術； Controller：負責收集轉化用戶的輸入。常用

17、一個SERVLET來實現(xiàn)；View和Controller都依賴于Model,但是Model既不依賴于View,也不依賴于Controller,這是分離的主要優(yōu)點之一,這樣Model可以單獨的建立和測試以便于代碼復用,View和Controller只需要Model提供數(shù)據(jù),它們不會知道、也不會關心數(shù)據(jù)是存儲在SQL Server還是Oracle數(shù)據(jù)庫中或者別的什么地方。4、WEB層框架Struts Struts是一個在JSP Model2基礎上實現(xiàn)的MVC框架,其主要的設計理念是通過控制器將表現(xiàn)邏輯和業(yè)務邏輯解耦,以提高系統(tǒng)的可維護性、可擴展性及可重用性。Struts框架的體系結構如下圖所示：下

18、面就上圖所示的體系結構圖分析Struts框架中的MVC組件。視圖：視圖部分主要由JSP頁面組成,其中沒有流程邏輯、業(yè)務邏輯和模型信息,只有標記。Struts自身包含了一組標記庫,這也是Struts的精華之一,靈活運用它們可以簡化JSP頁面的代碼,提高開發(fā)效率?？刂破鳎篠truts中的Controller主要是其自身提供的ActionServlet。ActionServlet接收所有來自客戶端的請求并根據(jù)配置文件中的定義將控制轉移到適當?shù)腁ction對象。模型：Struts沒有定義具體Model層的實現(xiàn),Model層通常是和業(yè)務邏輯緊密相關的,有持續(xù)化的要求。目前在商業(yè)領域和開源世界,都有一些優(yōu)

19、秀的工具可以為Model層的開發(fā)提供便利。5、業(yè)務邏輯層框架Spring Spring是一個解決了許多JavaEE開發(fā)中常見問題并能夠替代EJB技術的強大的輕量級框架。這里所說的輕量級指的是Spring框架本身,而不是指Spring只能用于輕量級的應用開發(fā)。Spring的輕盈體現(xiàn)在其框架本身的基礎結構以及對其他應用工具的支持和裝配能力。與EJB這種龐然大物相比,Spring可使程序研發(fā)人員把各個技術層次之間的風險降低。 Spring框架的核心是控制翻轉IoC/依賴注入DI機制。IoC是指由容器中控制組件之間的關系這里,容器是指為組件提供特定服務和技術支持的一個標準化的運行時的環(huán)境而非傳統(tǒng)實現(xiàn)中

20、由程序代碼直接操控,這種將控制權由程序代碼到外部容器的轉移,稱為翻轉。DI是對IoC更形象的解釋,即由容器在運行期間動態(tài)地將依賴關系注入到組件之中。Spring采用設值注入和構造子注入的機制,通過配置文件管理組建的協(xié)作對象,創(chuàng)建可以構造組件的IoC容器。這樣,不需要編寫工廠模式、單例模式或者其他構造的方法,就可以通過容器直接獲取所需的業(yè)務組件。Spring框架的結構如下圖所示。 Spring框架由七個定義明確的模塊組成,且每個模塊或組件都可以單獨存在,或者與其他一個或多個模塊聯(lián)合實現(xiàn)。Spring Core Container是一個用來管理業(yè)務組件的IoC容器,是Spring應用的核心；Spr

21、ing DAO和Spring ORM不僅提供數(shù)據(jù)訪問的抽象模塊,還集成了對Hibernate、JDO和iBatis等流行的對象關系映射框架的支持模塊,并且提供了緩沖連接池、事務處理等重要的服務功能,保證了系統(tǒng)的性能和數(shù)據(jù)的完整性；Sprnig Web模塊提供了Web應用的一些抽象封裝,可以將Struts、Webwork等Web框架與Spring整合成為適用于自己的解決方案。Spring框架可以成為企業(yè)級應用程序一站式的解決方案,同時它也是模塊化的框架,允許開發(fā)人員自由地挑選適合自己應用的模塊進行開發(fā)。Spring框架式是一個松耦合的框架,框架的部分耦合度被設計為最小,在各個層次上具體選用哪個框

22、架取決于開發(fā)者的需要。6、持久層框架Hibernate O/R mapping技術是為了解決關系型數(shù)據(jù)庫和面向?qū)ο蟮某绦蛟O計之間不匹配的矛盾而產(chǎn)生的。Hibernate是目前最為流行的O/R mapping框架,它也是開源軟件,它在關系型數(shù)據(jù)庫和Java對象之間做了一個自動映射,使得程序員可以以非常簡單的方式實現(xiàn)對數(shù)據(jù)庫的操作,它不僅負責從Java類到數(shù)據(jù)庫表格的映射,而且還提供數(shù)據(jù)查詢和檢索能力,并能大大減少花在SQL和JDBC手工數(shù)據(jù)處理上的開發(fā)時間。Hibernate工作原理如下圖所示：Hibernate通過對JDBC的封裝,向程序員屏蔽了底層的數(shù)據(jù)庫操作,使程序員專注于OO程序的開發(fā),

23、有助于提高開發(fā)效率。程序員訪問數(shù)據(jù)庫所需要做的就是為持久化對象編制xml映射文件。 底層數(shù)據(jù)庫的改變只需要簡單地更改初始化配置文件即可,不會對應用程序產(chǎn)生影響。Hibernate有自己的面向?qū)ο蟮牟樵冋Z言HQL,HQL功能強大,支持目前大部分主流的數(shù)據(jù)庫,如Oracle、DB2、MySQL、Microsoft SQL Server等,是目前應用最廣泛的O/R映射工具。Hibernate為快速開發(fā)應用程序提供了底層的支持。二、基于SSH框架的Web應用架構分析與設計前面分析了基于JavaEE的SSH框架技術,現(xiàn)代的企業(yè)開發(fā)中,越來越多地引入了多層架構設計模式。SSH就是其中之一,SSH架構是當前

24、主流的架構,在很多領域,包括金融、電信項目,大型門戶網(wǎng)站均選擇該架構作為業(yè)務支撐架構,開發(fā)流程也已經(jīng)非常成熟。但是該結構開發(fā)起來,依舊存在一些問題。分析這些問題,得先從SSH架構的組成說起。SSH為Struts+Spring+Hibernate的組成方式,Struts實現(xiàn)MVC,Spring負責架構的結合,Hibernate進行數(shù)據(jù)的持久化。通常其分層開發(fā)的結構圖如下：這樣的結構,系統(tǒng)從職責上分為四層：WEB層、業(yè)務邏輯層、數(shù)據(jù)持久層和實體層。其中使用Struts作為系統(tǒng)的整體基礎架構,負責MVC的分離,在Struts框架的模型部分,利用Hibernate框架對持久層提供支持,業(yè)務層用Spri

25、ng支持。具體做法是：用面向?qū)ο蟮姆治龇椒ǜ鶕?jù)需求提出一些模型,將這些模型實現(xiàn)為基本的Java對象,然后編寫基本的DAO接口,并給出Hibernate的DAO實現(xiàn),采用Hibernate架構實現(xiàn)的DAO類來實現(xiàn)Java類與數(shù)據(jù)庫之間的轉換和訪問,最后由Spring完成業(yè)務邏輯。系統(tǒng)的基本業(yè)務流程是：在WEB表示層中,首先通過JSP頁面實現(xiàn)交互界面,負責傳送請求和接收響應,然后Struts根據(jù)配置文件將ActionServlet接收到的Request委派給相應的Action處理。在業(yè)務層中,管理服務組件的Spring IoC容器負責向Action提供業(yè)務模型組件和該組件的協(xié)作對象數(shù)據(jù)處理組件完成

26、業(yè)務邏輯,并提供事務處理、緩沖池等容器組件以提升系統(tǒng)性能和保證數(shù)據(jù)的完整性。而在持久層中,則依賴于Hibernate的對象化映射和數(shù)據(jù)庫交互,處理DAO組件請求的數(shù)據(jù),并返回處理結果。采用上述開發(fā)模型,不僅實現(xiàn)了視圖、控制器與模型的徹底分離,而且還實現(xiàn)了業(yè)務邏輯層與持久層的分離。這樣無論前端如何變化,模型層只需很少的改動,并且數(shù)據(jù)庫的變化也不會對前端有所影響,大大提高了系統(tǒng)的可復用性。而且由于不同層之間耦合度小,有利于團隊成員并行工作,大大提高了開發(fā)效率。但是對于當前日益復雜化的WEB2.0的開發(fā),卻存在不少問題,歸納起來主要有以下的不足：DAO和服務層容易出現(xiàn)職責不明,由于按照MVC邏輯,業(yè)

27、務代碼應該寫在Struts Action里,但是其事務的提供,卻是配置在Service層。為了一組在邏輯上完整的數(shù)據(jù)操作業(yè)務邏輯,需要涉及兩個層Service、Action來進行編寫,遇到判斷的情況下,為了保證完整的事務操作,則需要將業(yè)務代碼移到Service層完成,而通常習慣了在Struts Action里調(diào)用多次Service而產(chǎn)生多個事務,但在出現(xiàn)Exception導致出錯時,操作之前調(diào)用的Service事務的業(yè)務數(shù)據(jù)沒有被回滾。當需要返回的數(shù)據(jù)供AJAX使用,操作JSON或XML的大量使用時。開發(fā)起來會很費力,一段同樣的業(yè)務代碼,為了使用AJAX和XML可能需要重新編寫一次,或者在同一

28、個ACTION里通過標志來判斷,對分層結構造成了比較糟糕的破壞。如果設計得不好,為了使用JSON和XML還得額外增加大量的配置,嚴重降低了開發(fā)效率。因此,為了克服這些缺點,對于SSH架構,進行了重新的分層,共享了業(yè)務代碼。簡化了開發(fā)、增強了與AJAX技術、XML技術的結合。提供了一種更高效的開發(fā)模式。其開發(fā)的結構圖如下：這個架構的優(yōu)點在于,由于業(yè)務代碼統(tǒng)一實現(xiàn)BusinessService接口,使得只需要相對固定的幾個Struts Action類調(diào)用Service層的方法,便可以完成工作。包括JSON格式輸出,XML輸出及WebService輸出均調(diào)用Service層方法來完成功能。這樣便實現(xiàn)

29、了業(yè)務代碼的分離,以及與前端框架的極大解耦。二、技術解決方案開發(fā)一款好的軟件產(chǎn)品,離不開一個好的開發(fā)過程。開發(fā)期間對過程的把控程度,往往會決定軟件產(chǎn)品的質(zhì)量好壞。因此,開發(fā)前期的計劃流程是必不可少的。本公司軟件系統(tǒng)的開發(fā)是按階段進行的,一般劃分為以下階段：可可行性分析需求分析概要設計詳細設計編碼測試修改完善驗收維護項 目可行性研究報告 軟件需求說明書概要設計說明書 數(shù)據(jù)庫設計說明書詳細設計說明書 測試計劃測試分析報告驗收報告用戶操作手冊1、可行性分析可行性分析的目的是明確系統(tǒng)的目的、功能和要求,了解目前所具備的開發(fā)環(huán)境和條件,分析的內(nèi)容有：在技術能力上是否可以支持在經(jīng)濟上效益如何在法律上是否符

30、合要求與部門、企業(yè)的經(jīng)營和發(fā)展是否吻合系統(tǒng)投入運行后的維護有無保障可行性討論的目的是判定軟件系統(tǒng)的開發(fā)有無價值,分析和討論的內(nèi)容形成系統(tǒng)開發(fā)計劃書,主要內(nèi)容有： 開發(fā)的目的及所期待的效果 系統(tǒng)的基本設想,涉及的業(yè)務對象和范圍 開發(fā)進度表,開發(fā)組織結構 開發(fā)、運行的費用 預期的系統(tǒng)效益 開發(fā)過程中可能遇到的問題及注意事項。2、需求分析需求分析是軟件系統(tǒng)開發(fā)中最重要的一個階段,直接決定著系統(tǒng)的開發(fā)質(zhì)量和成敗。因此必須要明確用戶的要求和應用現(xiàn)場環(huán)境的特點,了解系統(tǒng)應具有哪些功能、數(shù)據(jù)的流程和數(shù)據(jù)之間的聯(lián)系。需求分析應有用戶參加,到使用現(xiàn)場進行調(diào)研學習,軟件設計人員應虛心向技術人員和使用人員請教,共同

31、討論解決需求問題的方法,對調(diào)查結果進行分析,明確問題的所在。需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規(guī)格說明,評審。一、問題識別從系統(tǒng)角度來理解軟件,確定對所開發(fā)系統(tǒng)的綜合要求,并提出這些需求的實現(xiàn)條件,以及需求應該達到的標準。這些需求包括：功能需求,性能需求,環(huán)境需求,可靠性需求不發(fā)生故障的概率,安全保密需求,用戶界面需求,資源使用需求,軟件成本消耗與開發(fā)進度需求,預先估計以后系統(tǒng)可能達到的目標。二、分析與綜合逐步細化所有的軟件功能,找出系統(tǒng)各元素間的聯(lián)系,接口特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分。最后,綜合成系統(tǒng)的解決方案,給出要開

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

33、數(shù)據(jù)字典建立系統(tǒng)的邏輯模型。此種模型暫時與系統(tǒng)的物理因素無關。它是系統(tǒng)需求與物理實現(xiàn)的中間結構,它的主要結果是建立：系統(tǒng)結構圖、系統(tǒng)界面結構圖、系統(tǒng)出錯處理、以及系統(tǒng)開發(fā)技術說明。三、系統(tǒng)組織設計系統(tǒng)組織設計通過系統(tǒng)組織表描述本系統(tǒng)由哪些子系統(tǒng)組成,這些子系統(tǒng)與業(yè)務職能之間的關系,以及各個子系統(tǒng)的安裝地點。系統(tǒng)組織表的格式如下：子系統(tǒng)編號英文名稱中文名稱業(yè)務職能安裝地點備注其中：1、子系統(tǒng)編號給出本系統(tǒng)中指定子系統(tǒng)的順序編號。如果本系統(tǒng)末劃分為多個子系統(tǒng),僅由一個運行模塊組成；則本項內(nèi)容仍需要描述,但是本表內(nèi)容只有一行。在一個系統(tǒng)中有可能安裝若干個相同的子系統(tǒng),在這種情況下,應該視為一個子系統(tǒng)

34、,并且對多個安裝地點分別進行描述。如果相同的子系統(tǒng)通過系統(tǒng)設置,實現(xiàn)的業(yè)務職能具有明顯差異時,應該采用多行進行分別描述,并且在備注中說明其差異所在。2、子系統(tǒng)英文名稱給出本子系統(tǒ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è)務職能描述該子系統(tǒng)完成的核心業(yè)務。5、安裝地點描述該子系統(tǒng)實際安裝的部門、或者某個具體地點。6、備注針對該子系統(tǒng),

35、需要說明的其它有關問題。四、系統(tǒng)結構設計1、系統(tǒng)特性表系統(tǒng)特性是系統(tǒng)中完成某項具體操作的基本單元,它由入口參數(shù),出口參數(shù)以及處理過程三部分組成。系統(tǒng)特性可以具有操作界面,也可以沒有操作界面；可以被其它操作界面、或者系統(tǒng)特性調(diào)用,也可以調(diào)用其它操作界面、非操作界面、或者系統(tǒng)特性；但是不允許遞歸調(diào)用,包括間接遞歸調(diào)用。當系統(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)中文名

36、稱含義同上。4、特性編號整個系統(tǒng)所有特性的統(tǒng)一編號。5、系統(tǒng)特性英文名稱系統(tǒng)特性的英文正式名稱,將來用于軟件開發(fā)中,必須符合命名規(guī)范。6、系統(tǒng)特性中文名稱系統(tǒng)特性的中文正式名稱,來源于需求規(guī)格說明書中,系統(tǒng)特性一節(jié)中的有關描述。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)特性有關的其它注意事項。11、說明描述與該系統(tǒng)特性表有關的其它注意事項。五、系統(tǒng)接口設計1、系統(tǒng)接口表接口作為系統(tǒng)的一種輸入

37、輸出形式,分為網(wǎng)絡接口、數(shù)據(jù)庫接口、RS-232串行通訊接口、IEEE485串行總線接口、并行I/O接口等等多種類型。當系統(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)接口的正式名稱,必須符合通常習慣。6、接口類型指出該接口所傳輸?shù)臄?shù)據(jù)在該模塊中起到的作用。7、接口性質(zhì)指出該接口在通訊中起到的作用,這里的作用可以是：輸入

38、、輸出、雙向。8、接口速率指出該接口的傳輸速率。如果該接口依賴于其它通訊方式,那么傳輸速率將不高于它所依賴的其它通訊方式的速率。9、接口協(xié)議給出該接口實際使用的通訊協(xié)議。10、相關對象給出直接使用本接口的系統(tǒng)對象,這里的系統(tǒng)對象,可以是操作界面,也可以是系統(tǒng)特性。11、備注描述與該系統(tǒng)接口有關的其它注意事項。12、說明描述與該系統(tǒng)接口表有關的其它注意事項。六、系統(tǒng)完整性設計描述系統(tǒng)對象,所受到的邏輯約束關系。當系統(tǒng)由多個子系統(tǒng)組成時,每個子系統(tǒng)應分別使用一張系統(tǒng)完整性約束表進行描述。系統(tǒng)完整性約束表的格式如下：子系統(tǒng)編號子系統(tǒng)英文名稱子系統(tǒng)中文名稱約束編號完整性名稱相對對象名約束表達式備注說明

39、：其中：1、子系統(tǒng)編號含義同上。2、子系統(tǒng)英文名稱含義同上。3、子系統(tǒng)中文名稱含義同上。4、約束編號整個系統(tǒng)所有約束的統(tǒng)一編號。5、完整性名稱系統(tǒng)完整性約束的正式名稱,必須符合通常習慣。6、相對對象名完整性約束中的相關對象。7、約束表達式用一階邏輯表達式表達的約束方程式。8、備注描述與該系統(tǒng)完整性約束有關的其它注意事項。9、說明描述與該系統(tǒng)完整性約束表有關的其它注意事項。系統(tǒng)設計具體可根據(jù)系統(tǒng)的規(guī)模分成概要設計和詳細設計兩個階段,概要設計包括：劃分系統(tǒng)模塊每個模塊的功能確定用戶使用界面概要設計輸入輸出數(shù)據(jù)的概要設計報表概要設計數(shù)據(jù)之間的聯(lián)系、流程分析文件和數(shù)據(jù)庫表的邏輯設計硬件、軟件開發(fā)平臺的

40、確定有規(guī)律數(shù)據(jù)的規(guī)范化及數(shù)據(jù)惟一性要求。系統(tǒng)的詳細設計是對系統(tǒng)的概要設計進一步具體化,其主要工作有：文件和數(shù)據(jù)庫的物理設計輸入輸出記錄的方案設計對各子系統(tǒng)的處理方式和處理內(nèi)容進行細化設計編制程序設計任務書。程序說明書通常包括程序規(guī)范、功能說明、程序結構圖,通常用HPIPOHierarchy Plus Input Process Output圖描述。4、編碼根據(jù)程序設計任務書的要求,用計算機算法語言實現(xiàn)解題的步驟,主要工作包括：模塊的理解和進一步劃分以模塊為單位的邏輯設計,也就是模塊內(nèi)的流程圖的編制編寫代碼,用程序設計語言編制程序進行模塊內(nèi)功能的測試、單元測試。程序質(zhì)量的要求包括：滿足要求的確切

41、功能處理效率高操作方便,用戶界面友好程序代碼的可讀性好,函數(shù)、變量標識符合規(guī)范擴充性、維護性好。降低程序的復雜性也是十分重要的,系統(tǒng)的復雜性由模塊間的接口數(shù)來衡量,一般地講,n 個模塊的接口數(shù)的最大值為n/2；若是層次結構,n 個模塊的接口數(shù)的最小值為n-1。為使復雜性最小,對模塊的劃分設計常常采用層次結構。要注意編制的程序或模塊應容易理解、容易修改,模塊應相互獨立,對某一模塊的修改應對其他模塊的功能不產(chǎn)生影響,模塊間的聯(lián)系盡可能少。5.系統(tǒng)測試測試是為了發(fā)現(xiàn)程序中的錯誤,對于設計的軟件,出現(xiàn)錯誤是難免的。系統(tǒng)測試通常由經(jīng)驗豐富的設計人員設計測試方案和測試樣品,并寫出測試過程的詳細報告。系統(tǒng)測

42、試是在單元測試的基礎上進行的,包括：測試方案的設計；進行測試；寫出測試報告；用戶對測試結果進行評價。具體測試方式如下：黑盒測試黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結構。測試者把被測程序看成一個黑盒,不用關心程序的內(nèi)部結構。黑盒測試是在程序接口處進行測試,它只檢查程序功能是否能正常使用,程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息,并且保持外部信息的完整性。黑盒測試是基于用戶角度進行的測試。白盒測試本公司系統(tǒng)軟件測試的主要方法之一,也稱結構測試、邏輯驅(qū)動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內(nèi)部結構、算法等信息,這是從程序設計者的角度對程序進行的測

43、試。它的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率,提高代碼的質(zhì)量,發(fā)現(xiàn)代碼中隱藏的問題。 灰盒測試可以理解為靜態(tài)的白盒測試或動態(tài)的黑盒測試,灰盒就是界于黑白之間, 對軟件內(nèi)部有所了解, 但不見得到了如指掌的程度, 卻可以結合這些了解做些比黑盒多點的測試。文檔測試文檔測試涵蓋面很大,在軟件的各個版本中均有所使用。隨著軟件版本的變化,文檔測試的測試內(nèi)容也有所變化。在需求分析以及原型架構階段,文檔測試主要目標是： Sitemap、動作分解列表、數(shù)據(jù)庫ER圖、UML用例圖、流程圖、需求文檔等文檔。文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯,也不允許文檔內(nèi)容前后矛

44、盾。完整性是指文檔不可以漏掉關鍵性內(nèi)容?？衫斫庑允侵冈谖臋n中描述的語言要簡明易懂,不能讓別的開發(fā)人員拿到文檔時看不懂文檔的內(nèi)容。命名規(guī)范測試命名規(guī)范測試用于測試項目中的文件命名、代碼以及版本號等書寫是否符合規(guī)范。需求完整性測試需求完整性測試主要存在于需求探索階段,在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試,確認需求是否明確。另外,需求完整性測試也承擔著一部分澄清需求的任務。鏈接完整性測試在原型架構階段,鏈接完整性的測試是非常有必要的。該項測試任務主要是檢查假頁面中各種鏈接是否完整,是否指向目標位置,屬于檢查性的測試。 頁面完整性測試頁面完整性測試主要存在于集成測試階段

45、以及其后續(xù)其它階段中,測試頁面是否完整,頁面質(zhì)量是否達標,屬于檢查性測試。UI合理性測試UI合理性測試也就是人機交互界面的合理性,UI合理性測試的內(nèi)容很多,具體測試內(nèi)容如下： 提示、菜單、幫助的格式是否一致； 提示、菜單、幫助中的術語是否一致； 各個控件之間的對齊方式是否一致； 輸入界面和輸出界面在外觀、布局、交互方式上是否一致； 功能類似的相關界面在外觀、布局、交互方式上是否一致； 同一層次的文字在同一種提示場合一般情況、特殊字體、警告等在文字大小、字體、顏色、對齊方式方面是否一致,字體大小 是否與界面的大小比例協(xié)調(diào)； 多個連續(xù)界面依次出現(xiàn)的情況下,界面的外觀、操作方式是否一致； 系統(tǒng)是否拒

46、絕客戶的錯誤輸入并做出提示； 系統(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ù)庫表中的關系、索引、主鍵、約束是否正確。功能測試功能測試在軟件

47、項目的任何階段中都是重要的。實現(xiàn)功能,滿足客戶需求是軟件本身最大的使命。功能測試在任何階段下基本上都作為測試工作的第一項出現(xiàn)。該項測試任務主要為了測試已實現(xiàn)的功能是否滿足需求,是否正確,是否有價值以及是否完整。在黑盒和白盒測試狀態(tài)下,該測試均會被使用。功能測試中測試人員往往會忽略掉一些細節(jié)問題,比如：一個功能的實現(xiàn)必須要經(jīng)過6步操作才能完成,而且需要加入20條信息才能看得出測試結果,有的測試人員為了節(jié)省時間雖然做完了6步操作,但是沒有加入足量的信息,使得測試不全面,正是因為這樣而導致一些隱藏的BUG沒有被測試出來。所以說在功能測試中要按部就班的把所有要進行的測試功能每一步都執(zhí)行一遍,應該添加的

48、數(shù)據(jù)都添加完整,以避免遺漏掉BUG沒有測試出來。壓力測試壓力測試是為了發(fā)現(xiàn)在什么條件下您的應用程序的性能會變得不可接受。這通過改變應用程序的輸入以對應用程序施加越來越大的負載并測量在這些不同的輸入時性能的改變來實現(xiàn)的。這種操作也稱為負載測試,但是負載測試通常描述一種特定類型的壓力測試增加用戶數(shù)量以對應用程序進行壓力測試。對應用程序進行壓力測試最簡單的方法是手工改變輸入客戶機數(shù)量、需求大小、請求的頻率、請求的混合程度等等并描繪性能的變化。但是如果有許多輸入,或者需要在大的范圍內(nèi)改變輸入,那么你可以借助一個自動化的壓力測試工具來完成此測試。安全性測試安全性測試主要是測試系統(tǒng)在沒有授權的內(nèi)部或者外部

49、用戶對系統(tǒng)進行攻擊或者惡意破壞時如何進行處理,是否仍能保證數(shù)據(jù)和頁面的安全。測試人員可以學習一些黑客技術,來對系統(tǒng)進行攻擊。 另外,對操作權限的測試也包含在安全性測試中。具體測試內(nèi)容如下：執(zhí)行添加、刪除、修改等動作中是否做過登錄檢測。 退出系統(tǒng)之后的操作是否可以完成。 所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲,特殊字符為：！?#￥%*-+=、|；：？/,。 在帶有參數(shù)的回顯數(shù)據(jù)的動作中更改參數(shù),把參數(shù)改為特殊字符并加入操作語句看是否出錯。 測試表單中有沒有做標簽檢測,標簽檢測是否完整。 在插入表單中加入特殊的HTML代碼,例如：表單中的字本是否移動？。頁面腳本測試頁面中時常使用到J

50、avaScript腳本,為了降低頁面的出錯率,則必須對頁面腳本進行測試。其主要內(nèi)容包括：相關頁面中的腳本是否正常運行,JavaScript腳本是否有錯誤頁面。 提示文本測試提示文本測試從嚴格意義上來講應該屬于UI合理性測試的一部分,該項測試主要針對各個頁面中使用到的大量提示文檔進行測試,主要包括：表達不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。瀏覽器測試由于B/S結構項目是基于瀏覽器運行的,所以需要對瀏覽器進行必要的測試。該測試任務主要是軟件對各種瀏覽器IE5.5、IE6.0、 FireFox瀏覽器 的支持是否正常,在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器

51、中是否可以正常顯示。安裝測試在軟件項目的后期階段,會對做好的軟件進行打包把軟件做成安裝程序,以便用戶可以正確的安裝使用,所以需要對做好的安裝文件進行安裝功能方面的測試。該測試的主要任務是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。6、文檔資料文檔包括開發(fā)過程中的所有技術資料以及用戶所需的文檔,軟件系統(tǒng)的文檔一般可分為系統(tǒng)文檔和用戶文檔兩類。用戶文檔主要描述系統(tǒng)功能和使用方法,并不考慮這些功能是怎樣實現(xiàn)的,系統(tǒng)文檔描述系統(tǒng)設計、實現(xiàn)和測試等方面的內(nèi)容。文檔是影響軟件可維護性、可用性的決定因素,有句話講,系統(tǒng)編程人員的每一張紙片都要保留,所以文檔的編制是軟件開發(fā)過程中的

52、一項重要工作。系統(tǒng)文檔包括： 開發(fā)軟件系統(tǒng)在計劃 需求分析 設計 編制 調(diào)試 運行等階段的有關文檔。在對軟件系統(tǒng)進行修改時,系統(tǒng)文檔應同步更新,并注明修改者和修改日期,如有必要應注明修改原因,應切記過時的文檔是無用的文檔。用戶文檔包括：系統(tǒng)功能描述安裝文檔,說明系統(tǒng)安裝步驟以及系統(tǒng)的硬件配置方法用戶使用手冊,說明使用軟件系統(tǒng)方法和要求,疑難問題解答參考手冊,描述可以使用的所有系統(tǒng)設施,解釋系統(tǒng)出錯信息的含義及解決途徑。7、系統(tǒng)的運行與維護系統(tǒng)只有投入運行后,才能進一步對系統(tǒng)檢驗,發(fā)現(xiàn)潛在的問題,為了適應環(huán)境的變化和用戶要求的改變,可能會對系統(tǒng)的功能、使用界面進行修改。要對每次發(fā)現(xiàn)的問題和修改內(nèi)

53、容建立系統(tǒng)維護文檔,并使系統(tǒng)文檔資料同步更新。12.4.4 服務保證措施本公司軟件質(zhì)量保證由各項任務構成,這些任務的參與者有兩種人：軟件開發(fā)人員和質(zhì)量保證人員。前者負責技術工作,后者負責質(zhì)量保證的計劃、監(jiān)督、記錄、分析及報告工作。軟件開發(fā)人員通過采用可靠的技術方法和措施,進行正式的技術評審,執(zhí)行計劃周密的軟件測試來保證軟件產(chǎn)品的質(zhì)量。軟件質(zhì)量保證人員則輔助軟件開發(fā)組得到高質(zhì)量的最終產(chǎn)品。我們的軟件質(zhì)量保證計劃大體分為如下三大部分：把軟件研制合理地劃分為若干階段,并針對每個階段的特點,制定出質(zhì)量評審、評測的要求和措施。從軟件質(zhì)量的要求出發(fā),制定出相應的技術和管理規(guī)范,如軟件文檔規(guī)范、軟件編程規(guī)范

54、、軟件測試規(guī)范、軟件版本控制規(guī)范等。創(chuàng)建和積累公用模塊,向軟件工廠化方向發(fā)展。1、軟件研制的階段劃分及其質(zhì)量控制我們把軟件系統(tǒng)的研制劃分為8個階段,即總體需求分析、總體設計、各分系統(tǒng)的需求說明及概要設計、詳細設計、程序編制、自測試、組裝與驗收測試、試用和初步定型。我們規(guī)定,總體需求分析及總體設計需經(jīng)有關領導及管理專家評審認定。分系統(tǒng)的需求說明、概要設計及詳細設計需經(jīng)總工程師組織的技術評審組評審。評審前,多數(shù)分系統(tǒng)的需求說明及概要設計需經(jīng)有代表性的用戶審核認可,即分析和設計階段主要靠評審把關,編程和實施階段主要靠執(zhí)行規(guī)范和測試把關。每次評審的結果都有相應的記錄,并填寫相應的表格。2、軟件的文檔規(guī)

55、范系統(tǒng)開發(fā)的文檔要求是：每個分系統(tǒng)必須有需求說明、概要設計,每個子系統(tǒng)必須有詳細設計和操作使用說明。需求說明、概要設計和詳細設計必須串行完成,而且規(guī)定,詳細設計未經(jīng)評審通過不能進入正規(guī)編程。不寫設計就進入編程,這是軟件開發(fā)人員常犯的毛病,在我們的系統(tǒng)開發(fā)中這是不允許的。3、軟件編程規(guī)范開發(fā)中所有設計文件經(jīng)過認真的評審、推敲和認定后,軟件編程將是保證軟件質(zhì)量的一個重要環(huán)節(jié)。為保證這一環(huán)節(jié)的質(zhì)量,我們專門制定了編程的有關規(guī)范。其中最主要的是界面規(guī)范。需要強調(diào)的是,對界面的理解不應只限于屏幕格式和操作方法,界面設計應貫穿于軟件編制的全過程,我們的界面規(guī)范分為兩大部分：第一部分是設計原則,包括：一般原

56、則、屏幕格式設計原則、輸入過程設計原則、信息顯示設計原則、提示信息設計原則、報表設計原則、菜單設計原則、操作方法原則。它重點解決操作的方便性和直接性、顯示和提示的確定性、輸入的準確性、輸入輸出的一致性,以保證對用戶習慣和心理的良好適應性,給用戶一種愉快感,讓用戶產(chǎn)生一種喜愛感。第二部分是屏幕格式設計,包括：版權屏幕、登錄屏幕、單記錄錄入窗口、多記錄錄入窗口、查詢列表窗口、 主/細數(shù)據(jù)錄入窗口、命令按鈕格式。它的主要目標是,力求使屏幕格式簡煉、實用、直觀、醒目、格調(diào)一致,使操作使用方便。軟件編程規(guī)范更是一種設計和編程經(jīng)驗的總結,是對所用開發(fā)工具的深入認識和全面理解。這一規(guī)范本身的質(zhì)量直接關系到全

57、系統(tǒng)的編程效率和可移植性、軟件的可擴展性及可維護性、數(shù)據(jù)的可恢復性和系統(tǒng)的可靠性。特別是在客戶/服務器模式下工作的系統(tǒng),編程時對處理和數(shù)據(jù)的合理分布將直接影響到系統(tǒng)資源利用得是否充分、恰當,直接影響到整個系統(tǒng)的性價比。它包括：對象和控制命名規(guī)范、編程風格、數(shù)據(jù)校驗、環(huán)境配置與應用的可移植性、事件驅(qū)動、面向?qū)ο?、?shù)據(jù)庫訪問規(guī)范、數(shù)據(jù)及處理分布、出錯處理、安裝及設置。實踐證明,這一規(guī)范對保證程序質(zhì)量、提高軟件重用度,進而對提高編程效率、乃至提高系統(tǒng)的可靠性均起了重要作用。4、軟件測試規(guī)范軟件測試是在設計階段保證軟件質(zhì)量的最后一關。從測試手段來說,我們把整個測試分為白盒測試和黑盒測試,并在軟件編制過

58、程中交叉使用。指派對開發(fā)工具認識最深入、編程經(jīng)驗最豐富的同志從事白盒測試；指派對工作流程最熟悉、對操作使用研究和體會最細致的同志從事黑盒測試。從測試過程來說,又分為兩步：自測試和組裝驗收測試。自測試是軟件編制者自己設計測試用例,自己驗證；組裝和驗收測試則是按照需求說明和工作流程全面設計測試案例,進行全面測試。工作流程、數(shù)據(jù)流程、各子系統(tǒng)之間及各模塊之間的接口是驗收測試的重點之一。整個測試階段必然是一個發(fā)現(xiàn)問題修改完善再測試的過程,而且可能多次反復。此時,最重要的是要把握住兩點：一是每提出一個修改,都需經(jīng)過總體設計師和分系統(tǒng)設計者的認真研究討論,既要保證軟件的正確性、流程的合理性和功能的完備性,

59、又要保證總體設計思想和軟件設計風格不受破壞,即保證軟件的整體質(zhì)量；二是程序編制者和測試者都要有足夠的耐心和良好的協(xié)作精神,都要有對軟件質(zhì)量負責的責任感。無論自測試,還是組裝及驗收測試,都是極其細致而又繁瑣的過程。不少技術人員愿意搞設計和編程,而不愿在測試方面多花功夫。軟件開發(fā)的管理者對這種傾向需嚴密注視、盡力防范,同時應做出具體規(guī)定,作為軟件設計的法規(guī),要求大家嚴格遵守。測試規(guī)范的概要如下在自測試階段制定了自測試方法和自測試過程。自測試方法重點規(guī)定了兩點：一是白盒測試、人工審查與機器執(zhí)行相結合；二是給出了測試用例設計原則,即模塊內(nèi)部和模塊間的測試用例設計原則及重點檢查的內(nèi)容。自測試過程分為代碼

60、審查、模塊測試、組裝測試和整理測試報告四個過程。規(guī)范中詳細規(guī)定了每一過程的細節(jié)和要求。組裝及驗收測試規(guī)范中同樣規(guī)定了測試方法和測試過程。其中,重點強調(diào)三點：一是再次推敲流程是否合理,功能是否齊全；二是測試用例設計必須考慮如下幾方面要求：功能測試、性能測試、大數(shù)據(jù)量測試、可靠性測試、可恢復性測試、多用戶測試、安裝測試和配置測試；三是要重視模塊和子系統(tǒng)之間的接口測試。5、軟件版本控制版本控制是對已做成的軟件在發(fā)展過程中的一種質(zhì)量管理,各大公司對自己的軟件均有一套版本控制方法。我們開發(fā)的軟件系統(tǒng)絕不是一錘子買賣,推出了第一期軟件的試用版,還會有第二期軟件補充進來,兩期軟件到一定階段都將定為正式版,而