1、軟件開發文檔模板附錄A軟件需求分析報告文檔模板附錄B軟件概要設計報告文檔模板附錄C軟件詳細設計報告文檔模板附錄D軟件數據庫設計報告文檔模板附錄E軟件測試(驗收)大綱目錄1. 范圍42. 總體要求42.1 總體功能要求42.2 軟件開發平臺要求42.3 軟件項目的開發實施過程管理要求52.3.1 軟件項目實施過程總體要求52.3.2 軟件項目實施變更要求52.3.3 軟件項目實施里程碑控制63. 軟件開發63.1 軟件的需求分析63.1.1 需求分析63.1.2 需求分析報告的

2、編制者73.1.3 需求報告評審73.1.4 需求報告格式73.2 軟件的概要設計73.2.1 概要設計73.2.2 編寫概要設計的要求73.2.3 概要設計報告的編寫者83.2.4 概要設計和需求分析、詳細設計之間的關系和區別83.2.5 概要設計的評審83.2.6 概要設計格式83.3 軟件的詳細設計83.3.1 詳細設計83.3.2 特例83.3.3 詳細設計的要求83.3.4 數據庫設計93.3.5 詳細設計的評審93.3.6 

3、詳細設計格式93.4 軟件的編碼93.4.1 軟件編碼93.4.2 軟件編碼的要求93.4.3 編碼的評審93.4.4 編程規范及要求93.5 軟件的測試93.5.1 軟件測試93.5.2 測試計劃103.6 軟件的交付準備103.6.1 交付清單103.7 軟件的鑒定驗收103.7.1 軟件的鑒定驗收103.7.2 驗收人員103.7.3 驗收具體內容113.7.4 軟件驗收測試大綱113.8 培訓113.8.1 系統應用培

4、訓113.8.2 系統管理的培訓（可選）11  1. 范圍本指南用于指導軟件開發者為南京市交通局開發軟件項目的過程，通過規范軟件項目承擔單位的開發過程達到提高軟件質量，降低維護成本的目的。開發者應根據本指南進行軟件開發和編制軟件開發文檔。本指南是對軟件項目承擔單位的基本要求。在本指南的附錄A至E中提供了文檔的編寫模板供開發者參考，在進行具體軟件開發時，開發者可根據實際情況采編寫，但必須提供雙方約定的文檔，文檔中約定的內容必須描述清楚。2. 總體要求2.1 總體功能要求網絡應用環境以Internet/Intranet技術為核心。開發者應

5、在充分分析需求的基礎上，選擇采用B/S結構或者C/S結構。軟件系統的數據庫應依照南京市交通局信息化數據庫建設規范進行設計和建設。本指南中沒有規定開發者采用何種具體的軟件工程開發方法，開發者可根據項目具體特點、自身擅長來選擇采用面向過程的方法、面向對象的方法或面向數據的方法，但建議開發    商使用面向對象軟件工程的方法，如：采用目前被廣泛使用的RUP(Rational Unified Process)方法來進行分析、設計和開發。2.2 軟件開發平臺要求開發者開發的軟件必須能夠在南京市交通局規定的軟件平臺上正常運行。目前軟件平臺為：數據庫管理系統

6、：Oracle 9i以上版本中間件(應用服務器)系統：IBM WebSphereOA系統：Lotus Domino/Notes網絡架構：完全支持TCP/IP協議開發工具或技術體系：為保證軟件的上下兼容性，開發者應選擇比較通用的開發工具的較新版本進行開發，如Microsoft Visual Studio.Net，Borland Delphi，C+ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。   2.3 軟件項目的開發實施過程管理要求2.3.1 軟件項目實施過程總體要求 

7、;              （一）開發者提交軟件開發工作大綱，交通局組織專家組對工作大綱進行評審，并提出整改意見。               （二）通過評審后，開發者根據整改意見完善工作大綱，經過交通局認可后組織項目組進行軟件開發。軟件開發工作按照需求分析、概要設計、詳細設計、編碼、測試等幾個階段進行，在

8、開發過程中，開發者需分階段提交相關文檔。               （三）在軟件開發工作完成后，開發者應向交通局提交完整的軟件文檔，交通局組織驗收組對軟件進行驗收審查。2.3.2 軟件項目實施變更要求在開發過程中，需求或設計不可避免地需要發生變更，相關變更必須經過交通局書面同  意方可進行。在需求或設計發生變更時，需要對原有文檔進行修改，并提供完整的變更記錄，  以使變更處于可控制的狀態。變更單

9、如下表所示：表 2-1 變更單需求變更申請申請變更的需求文檔        輸入名稱，版本，日期等信息變更的內客及其理由                               

10、0;   評估需求變更將對項目造成的影響                                            &

11、#160;                         申請人簽字                       &#

12、160;            變更申請的審批意見 項目經理簽字  審批意見：                               

13、                    簽字   日期               客戶簽字(合同項目)  審批意見：       

14、;                                           簽字   日期   &

15、#160;           更改需求文檔變更后的需求文檔  輸入名稱，版本，完成日期等信息                               &#

16、160;       更改人簽字                                   重新評審需求文檔 需求評審小組簽字   

17、;評審意見：                                                 

18、                                    簽字   日期          &#

19、160;    變更結束項目經理簽字                           簽字   日期 2.3.3 軟件項目實施里程碑控制交通局將分四個階段進行把關，召開專家審查會。    

20、0;          （一） 需求分析（結合原型進行審查）確認；               （二） 概要設計+數據庫設計；               （三） 預驗收

21、（試運行后）；               （四） 正式驗收（推廣使用后）。3. 軟件開發合同簽訂以后，項目承擔單位即可組織項目組進行軟件開發工作。軟件開發必須嚴格按照軟件工程的要求進行。開發過程包括開發者的活動和任務。此過程由軟件需求分析、概要設計、詳細設計、編碼、測試、驗收、鑒定等活動組成。3.1 軟件的需求分析3.1.1 需求分析首先，開發者和交通局應共同對交通局的應用需求作充分的調研，提交完整的需求

22、分析  報告。在需求分析報告中必須描述的基本問題是：功能、性能、強加于實現的設計限制、屬 性、外部接口。應當避免把設計或項目需求寫入需求分析報告中。它必須說明由軟件獲得的  結果，而不是獲得這些結果的手段。軟件需求可以用若干種方法來表達，如通過輸入、輸出說明；使用代表性的例子；用規范化的模型。開發者應盡可能地使用模型的方式，因為這是表達復雜需求的精確和有效的方法。比如用統一建模語言（UML）來描述需求。編寫需求分析報告的要求a無歧義性對最終產品的每一個特性用某一術語描述；若某一術語在某一特殊的行文中使用時具有多種含義，那么應對該術語的每種含義做

23、出解釋并指出其適用場合。b完整性需求分析報告應該包括全部有意義的需求，無論是關系到功能的、性能的、設計約束的、還是關系到外部接口方面的需求；對所有可能出現的輸入數據的響應予以定義，要對合法和非合法的輸入值的響應做出規定；填寫全部插圖、表、圖示標記等；定義全部術語和度量單位。c可驗證性需求分析報告描述的每一個需求應是可以驗證的。可以通過一個有限處理過程來檢查軟件產品是否滿足需求。d一致性在需求分析報告中的各個需求的描述不能互相矛盾。e可修改性需求分析報告應具有一個有條不紊、易于使用的內容組織；沒有冗余，即同一需求不能在需求分析報告中出現多次。f可追蹤性每一個需求的源流必須清晰，在進一步產生和改變

24、文件編制時，可以方便地引證每一個需求。g運行和維護階段的可使用性需求分析報告必須滿足運行和維護階段的需要。在需求分析報告要寫明功能的來源和目的。3.1.2 需求分析報告的編制者需求分析報告應由交通局和開發者雙方共同完成。其中：交通局負責根據實際需要提出希望軟件實現的功能；軟件開發者根據交通局提出的性能需求，結合軟件開發編寫需求分析。3.1.3 需求報告評審在軟件需求分析工作完成后，軟件開發者應向交通局提交軟件需求分析報告。交通局組織有關人員對需求進行評審，以決定軟件需求是否完善和恰當。評審完成后，就可以進入軟件的設計階段。3.1.4 需求報告格式軟件需求分析報告需

25、按一定的格式進行編寫，具體的軟件需求分析報告文檔編寫模板請見附錄A。3.2 軟件的概要設計3.2.1 概要設計在交通局和開發者雙方認可的需求分析報告基礎上，開發者進行下步的工作。    首先，開發者需要對軟件系統進行概要設計，即系統設計。概要設計需要對軟件系統的設計    進行考慮，包括系統的基本處理流程、系統的組織結構、模塊劃分、功能分配、接口設計、    運行設計、數據結構設計和出錯處理設計等，為軟件的詳細設計提供基礎。3.2.2 編寫概要設

26、計的要求a一致性概要設計的要求應該與需求分析報告所描述的需求一致。同時，概要設計的各項要求之間也應該一致。b合理性概要設計所提出的設計方法和標準應該是合理的、恰當的。c可追蹤性對概要設計所提出的各項要求應該可以得到它的清晰的源流，即在需求分析報告客戶有明確的需求描述。d可行性根據概要設計進行詳細設計、操作和維護應該是可行的。3.2.3 概要設計報告的編寫者概要設計報告由開發者根據需求分析報告的要求進行編寫。3.2.4 概要設計和需求分析、詳細設計之間的關系和區別 需求分析不涉及具體的技術實現，而概要設計注重于從宏觀上和框架上來描述采用何種技術手段、方法來實現這些需

27、求。詳細設計相對概要設計更注重于微觀上和框架內的設計，    是編碼的依據。概要設計是指導詳細設計的依據。3.2.5 概要設計的評審在軟件概要設計工作完成后，軟件開發者應向交通提交軟件系統概要設計報告。在交通局對概要設計報告評審通過后，即可進入詳細設計階段。3.2.6 概要設計格式軟件系統概要設計報告需按一定的格式進行編寫，具體的軟件系統概要設計報    告文檔編寫模板請見附錄B。3.3 軟件的詳細設計3.3.1 詳細設計在概要設計的基礎上，開發者需要進行軟件系統的詳細設計。

28、在詳細設計中，描述實    現具體模塊所涉及到的主要算法、數據結構、類的層次結構及調用關系，需要說明軟件系統各個層次中的每一個程序(每個模塊或子程序)的設計考慮，以便進行編碼和測試。應當保證    軟件的需求完全分配給整個軟件。詳細設計應當足夠詳細，能夠根據詳細設計報告進行編碼。3.3.2 特例如果軟件系統比較簡單，層次較少，可以不必進行專門的詳細設計，而和概要設計結合起來。3.3.3 詳細設計的要求a一致性詳細設計的要求應該與需求分析報告所描述的需求、與概要設計一致。同時，詳細設計的各項要求之

29、間也應該是一致的。b合理性詳細設計所提出的設計方法和標準應該是合理的、恰當的。c可追蹤性對詳細設計所提出的各項要求應該可以得到它的清晰的源流，即可在需求分析報告、概要設計報告中有明確的需求描述。d可行性根據詳細設計進行編碼、測試、操作和維護應該是可行的。3.3.4 數據庫設計如果軟件產品需要使用到數據庫，軟件的詳細設計應包括對數據庫的設計。數據庫設計應在軟件的需求分析、概要設計完成之后、詳細設計的其它工作之前進行。在進行數據庫設計時，應當按照交通局制定的南京市交通局信息化數據庫建設規范要求進行。3.3.5 詳細設計的評審在軟件詳細設計完成后，軟件開發者應向交通局提交軟件系統

30、數據庫設計報告和軟件系統詳細設計報告。在交通局對軟件系統數據庫設計報告、軟件系統詳細設計報告評審通過后，即可進入軟件編碼階段。3.3.6 詳細設計格式軟件系統詳細設計報告、軟件系統數據庫設計報告需按一定的格式進行編寫，    具體的軟件系統詳細設計報告文檔編寫模板和軟件系統數據庫設計報告文檔編寫模    板請見附錄C、附錄D。3.4 軟件的編碼3.4.1 軟件編碼在軟件編碼階段，開發者根據軟件系統詳細設計報告中對數據結構、算法分析和模塊實現等方面的設計要求，開始具體的編寫程序工作，分別

31、實現各模塊的功能，從而實現對目標系統的功能、性能、接口、界面等方面的要求。3.4.2 軟件編碼的要求a模塊化編碼b代碼可讀性c可維護性d模塊接口標準化e界面風格統一e注釋的應用3.4.3 編碼的評審為了盡早發現軟件中的障礙，提高軟件產品的質量，開發者在編碼的過程中應該強調代碼評審工作。將代碼評審報告作為文檔的一部分，提交給交通局。3.4.4 編程規范及要求為了提高編程實現的質量，軟件的程序設計必須遵照國家頒布的相關編程規范。主要內容包括：規范化的程序內部文檔、數據結構的詳細說明、清晰的語句結構、編碼規范。編碼規范的內容包括命名規范、界面規范、提示及幫助信息規范、熱

32、鍵定義等。其中數據庫部分應遵守南京市交通局信息化數據庫建設規范的要求。在軟件編碼的同時應進行單元測試。3.5 軟件的測試3.5.1 軟件測試為了盡早發現軟件產品中的錯誤，從而達到提高軟件質量、降低軟件維護的費用，開發者應在編碼過程中對各個模塊的程序代碼進行單元測試，系統集成時進行集成測試，系統集成完成后對整個軟件進行系統測試。單元測試是在軟件開發過程中針對程序模塊進行正確性檢驗。集成測試是在單元測試的基礎上，將所有模塊按照設計要求組裝成系統或子系統，對模塊組裝過程和模塊接口進行正確性檢驗。軟件系統測試不僅是檢測軟件的整體行為表    

33、現，從另一個側面看，也是對軟件開發設計的再確認。進行軟件系統測試工作時。測試主要包括界面測試、可用性測試、功能測試、穩定性(強度)測試、性能測試、強壯性(恢復)測試、邏輯性測試、破壞性測試、安全性測試等。開發者針對單元測試，集成測試，系統測試分別制定測試計劃。集成測試需要根據需求分析報告和概要設計制作測試用例，并須經過評審。軟件測試按照測試計劃、需求分析報告的要求進行，最后形成軟件測試報告。3.5.2 測試計劃在軟件編碼開始之前，開發者應向交通局提交測試計劃，在軟件交付時，開發者應向交通局提交軟件測試報告，以確保開發者的軟件得到了充分的測試。開發的軟件必須經過充分的測試證明其符合設計要求、運行穩定、安全可用方可交付交通局。3.6 軟件的交付準備3.6.1 交付清單在軟件測試證明軟件達到要求后，