目錄
1. 圍1
2. 總體要求1
2.1總體功能要求1
2.2軟件開發平臺要求1
2.3軟件項目的開發實施過程管理要求2
2.3.1 軟件項目實施過程總體要求2
2.3.2 軟件項目實施變更要求2
2.3.3 軟件項目實施里程碑控制2
3. 軟件開發3
3.1軟件的需求分析3
3.1.1 需求分析3
3.1.2 需求分析報告的編制者4
3.1.3 需求報告評審4
3.1.4 需求報告格式4
3.2軟件的概要設計4
3.2.1 概要設計4
3.2.2 編寫概要設計的要求4
3.2.3 概要設計報告的編寫者4
3.2.4 概要設計和需求分析、詳細設計之間的關系和區別4
3.2.5 概要設計的評審4
3.2.6 概要設計格式4
3.3軟件的詳細設計5
3.3.1 詳細設計5
3.3.2 特例5
3.3.3 詳細設計的要求5
3.3.4 數據庫設計5
3.3.5 詳細設計的評審5
3.3.6 詳細設計格式5
3.4軟件的編碼5
3.4.1 軟件編碼5
3.4.2 軟件編碼的要求5
3.4.3 編碼的評審6
3.4.4 編程規與要求6
3.5軟件的測試6
3.5.1 軟件測試6
3.5.2 測試計劃6
3.6軟件的交付準備6
3.6.1 交付清單6
3.7軟件的鑒定驗收7
3.7.1 軟件的鑒定驗收7
3.7.2 驗收人員7
3.7.3 驗收具體容7
3.7.4 軟件驗收測試大綱7
3.8培訓7
3.8.1 系統應用培訓7
3.8.2 系統管理的培訓（可選）8
附錄A 軟件需求分析報告文檔模板9
附錄B 軟件概要設計報告文檔模板21
附錄C 軟件詳細設計報告文檔模板33
附錄D 軟件數據庫設計報告文檔模板43
附錄E 軟件測試(驗收)大綱錯誤!未定義書簽。5
1. 圍
本指南用于指導軟件開發者為市交通局開發軟件項目的過程，通過規軟件項目承擔單位的開發過程達到提高軟件質量，降低維護成本的目的。開發者應根據本指南進行軟件開發和編制軟件開發文檔。本指南是對軟件項目承擔單位的基本要求。在本指南的附錄A至E中提供了文檔的編寫模板供開發者參考，
在進行具體軟件開發時，開發者可根據實際情況采編寫，但必須提供雙方約定的文檔，文檔中約定的容必須描述清楚。
2. 總體要求
2.1 總體功能要求
網絡應用環境以Internet/Intranet技術為核心。
開發者應在充分分析需求的基礎上，選擇采用B/S結構或者C/S結構。
軟件系統的數據庫應依照《市交通局信息化數據庫建設規》進行設計和建設。
本指南中沒有規定開發者采用何種具體的軟件工程開發方法，開發者可根據項目具體特點、自身擅長來選擇采用面向過程的方法、面向對象的方法或面向數據的方法，但建議開發商使用面向對象軟件工程的方法，如：采用目前被廣泛使用的RUP(Rational Unified Process)方法來進行分析、設計和開發。
2.2 軟件開發平臺要求
開發者開發的軟件必須能夠在市交通局規定的軟件平臺上正常運行。目前軟件平臺為：數據庫管理系統：
Oracle 9i以上版本
中間件(應用服務器)系統：
IBMWebSphere
OA系統：
Lotus Domino/Notes
網絡架構：
完全支持TCP/IP協議
開發工具或技術體系：
為保證軟件的上下兼容性，開發者應選擇比較通用的開發工具的較新版本進行開發，如Microsoft Visual Studio.Net，Borland Delphi，C++ Builder, 或J2EE(Java2 P1atform Enterpri Edition)等。
2.3 軟件項目的開發實施過程管理要求
2.3.1 軟件項目實施過程總體要求
（一）開發者提交軟件開發工作大綱，交通局組織專家組對工作大綱進行評審，并提出整改意見。
（二）通過評審后，開發者根據整改意見完善工作大綱，經過交通局認可后組織項目組進行軟件開發。軟件開發工作按照需求分析、概要設計、詳細設計、編碼、測試等幾個階段進行，在開發過程中，開發者需分階段提交相關文檔。
（三）在軟件開發工作完成后，開發者應向交通局提交完整的軟件文檔，交通局組織驗收組對軟件進行驗收審查。
2.3.2 軟件項目實施變更要求
在開發過程中，需求或設計不可避免地需要發生變更，相關變更必須經過交通局書面同意方可進行。在需求或設計發生變更時，需要對原有文檔進行修改，并提供完整的變更記錄，以使變更處于可控制的狀態。變更單如下表所示：
表 2-1 變更單
2.3.3 軟件項目實施里程碑控制
交通局將分四個階段進行把關，召開專家審查會。
（一）需求分析（結合原型進行審查）確認；
（二）概要設計+數據庫設計；
（三）預驗收（試運行后）；
（四）正式驗收（推廣使用后）。
3. 軟件開發
合同簽訂以后，項目承擔單位即可組織項目組進行軟件開發工作。軟件開發必須嚴格按照軟件工程的要求進行。開發過程包括開發者的活動和任務。此過程由軟件需求分析、概要設計、詳細設計、編碼、測試、驗收、鑒定等活動組成。
3.1 軟件的需求分析
3.1.1 需求分析
首先，開發者和交通局應共同對交通局的應用需求作充分的調研，提交完整的需求分析報告。在需求分析報告中必須描述的基本問題是：功能、性能、強加于實現的設計限制、屬性、外部接口。應當避免把設計或項目需求寫入需求分析報告中。它必須說明由軟件獲得的結果，而不是獲得這些結果的手段。
軟件需求可以用若干種方法來表達，如通過輸入、輸出說明；使用代表性的例子；用規化的模型。開發者應盡可能地使用模型的方式，因為這是表達復雜需求的精確和有效的方法。比如用統模語言（UML）來描述需求。
編寫需求分析報告的要求
a．無歧義性
對最終產品的每一個特性用某一術語描述；若某一術語在某一特殊的行文中使用時具有多種含義，那么應對該術語的每種含義做出解釋并指出其適用場合。
b．完整性
需求分析報告應該包括全部有意義的需求，無論是關系到功能的、性能的、設計約束的、還是關系到外部接口方面的需求；對所有可能出現的輸入數據的響應予以定義，要對合法和非合法的輸入值的響
應做出規定；填寫全部插圖、表、圖示標記等；定義全部術語和度量單位。
c．可驗證性
需求分析報告描述的每一個需求應是可以驗證的。可以通過一個有限處理過程來檢查軟件產品是否滿足需求。
d．一致性
在需求分析報告中的各個需求的描述不能互相矛盾。
e．可修改性
需求分析報告應具有一個有條不紊、易于使用的容組織；沒有冗余，即同一需求不能在需求分析報告中出現多次。
f．可追蹤性
每一個需求的源流必須清晰，在進一步產生和改變文件編制時，可以方便地引證每一個需求。
g．運行和維護階段的可使用性
需求分析報告必須滿足運行和維護階段的需要。在需求分析報告要寫明功能的來源和目的。
