|
1. 范圍本指南用于指導軟件開發(fā)者為南京市交通局開發(fā)軟件項目的過程,，通過規(guī)范軟件項目承擔單位的開發(fā)過程達到提高軟件質量,，降低維護成本的目的。開發(fā)者應根據(jù)本指南進行軟件開發(fā)和編制軟件開發(fā)文檔,。本指南是對軟件項目承擔單位的基本要求。在本指南的附錄A至E中提供了文檔的編寫模板供開發(fā)者參考，在進行具體軟件開發(fā)時,，開發(fā)者可根據(jù)實際情況采編寫,，但必須提供雙方約定的文檔，文檔中約定的內容必須描述清楚,。 2. 總體要求2.1 總體功能要求網(wǎng)絡應用環(huán)境以Internet/Intranet技術為核心,。 開發(fā)者應在充分分析需求的基礎上,，選擇采用B/S結構或者C/S結構。 軟件系統(tǒng)的數(shù)據(jù)庫應依照《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》進行設計和建設,。 本指南中沒有規(guī)定開發(fā)者采用何種具體的軟件工程開發(fā)方法,，開發(fā)者可根據(jù)項目具體特點、自身擅長來選擇采用面向過程的方法,、面向對象的方法或面向數(shù)據(jù)的方法,，但建議開發(fā) 商使用面向對象軟件工程的方法，如：采用目前被廣泛使用的RUP(Rational Unified Process)方法來進行分析,、設計和開發(fā),。 2.2 軟件開發(fā)平臺要求開發(fā)者開發(fā)的軟件必須能夠在南京市交通局規(guī)定的軟件平臺上正常運行。目前軟件平臺為： 數(shù)據(jù)庫管理系統(tǒng)： Oracle 9i以上版本 中間件(應用服務器)系統(tǒng)： IBM WebSphere OA系統(tǒng)： Lotus Domino/Notes 網(wǎng)絡架構： 完全支持TCP/IP協(xié)議 開發(fā)工具或技術體系： 為保證軟件的上下兼容性,，開發(fā)者應選擇比較通用的開發(fā)工具的較新版本進行開發(fā),，如Microsoft Visual Studio.Net，Borland Delphi,，C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等,。 2.3 軟件項目的開發(fā)實施過程管理要求2.3.1 軟件項目實施過程總體要求（一）開發(fā)者提交軟件開發(fā)工作大綱，交通局組織專家組對工作大綱進行評審,，并提出整改意見,。 （二）通過評審后，開發(fā)者根據(jù)整改意見完善工作大綱,，經(jīng)過交通局認可后組織項目組進行軟件開發(fā),。軟件開發(fā)工作按照需求分析、概要設計,、詳細設計,、編碼、測試等幾個階段進行,，在開發(fā)過程中,，開發(fā)者需分階段提交相關文檔。 （三）在軟件開發(fā)工作完成后,，開發(fā)者應向交通局提交完整的軟件文檔,，交通局組織驗收組對軟件進行驗收審查。 2.3.2 軟件項目實施變更要求在開發(fā)過程中,，需求或設計不可避免地需要發(fā)生變更,，相關變更必須經(jīng)過交通局書面同 意方可進行。在需求或設計發(fā)生變更時,，需要對原有文檔進行修改,，并提供完整的變更記錄， 以使變更處于可控制的狀態(tài)。變更單如下表所示： 表 2-1 變更單
2.3.3 軟件項目實施里程碑控制交通局將分四個階段進行把關,，召開專家審查會。 （一） 需求分析（結合原型進行審查）確認,； （二） 概要設計+數(shù)據(jù)庫設計,； （三） 預驗收（試運行后）； （四） 正式驗收（推廣使用后）,。 3. 軟件開發(fā)合同簽訂以后,，項目承擔單位即可組織項目組進行軟件開發(fā)工作。軟件開發(fā)必須嚴格按照軟件工程的要求進行,。開發(fā)過程包括開發(fā)者的活動和任務,。此過程由軟件需求分析、概要設計,、詳細設計,、編碼、測試,、驗收,、鑒定等活動組成。 3.1 軟件的需求分析3.1.1 需求分析首先,，開發(fā)者和交通局應共同對交通局的應用需求作充分的調研,，提交完整的需求分析 報告。在需求分析報告中必須描述的基本問題是：功能,、性能,、強加于實現(xiàn)的設計限制、屬 性,、外部接口,。應當避免把設計或項目需求寫入需求分析報告中。它必須說明由軟件獲得的 結果,，而不是獲得這些結果的手段,。 軟件需求可以用若干種方法來表達，如通過輸入,、輸出說明；使用代表性的例子,；用規(guī)范化的模型,。開發(fā)者應盡可能地使用模型的方式，因為這是表達復雜需求的精確和有效的方法,。比如用統(tǒng)一建模語言（UML）來描述需求,。 編寫需求分析報告的要求 a．無歧義性 對最終產品的每一個特性用某一術語描述,；若某一術語在某一特殊的行文中使用時具有多種含義，那么應對該術語的每種含義做出解釋并指出其適用場合,。 b．完整性 需求分析報告應該包括全部有意義的需求,，無論是關系到功能的、性能的,、設計約束的,、還是關系到外部接口方面的需求；對所有可能出現(xiàn)的輸入數(shù)據(jù)的響應予以定義,，要對合法和非合法的輸入值的響應做出規(guī)定,；填寫全部插圖、表,、圖示標記等,；定義全部術語和度量單位。 c．可驗證性 需求分析報告描述的每一個需求應是可以驗證的,?？梢酝ㄟ^一個有限處理過程來檢查軟件產品是否滿足需求。 d．一致性 在需求分析報告中的各個需求的描述不能互相矛盾,。 e．可修改性 需求分析報告應具有一個有條不紊,、易于使用的內容組織；沒有冗余,，即同一需求不能在需求分析報告中出現(xiàn)多次,。 f．可追蹤性 每一個需求的源流必須清晰，在進一步產生和改變文件編制時,，可以方便地引證每一個需求,。 g．運行和維護階段的可使用性 需求分析報告必須滿足運行和維護階段的需要。在需求分析報告要寫明功能的來源和目的,。 3.1.2 需求分析報告的編制者需求分析報告應由交通局和開發(fā)者雙方共同完成,。其中：交通局負責根據(jù)實際需要提出希望軟件實現(xiàn)的功能；軟件開發(fā)者根據(jù)交通局提出的性能需求,，結合軟件開發(fā)編寫需求分析,。 3.1.3 需求報告評審在軟件需求分析工作完成后，軟件開發(fā)者應向交通局提交《軟件需求分析報告》,。交通局組織有關人員對需求進行評審,，以決定軟件需求是否完善和恰當。評審完成后,，就可以進入軟件的設計階段,。 3.1.4 需求報告格式《軟件需求分析報告》需按一定的格式進行編寫，具體的《軟件需求分析報告》文檔編寫模板請見附錄A。 3.2 軟件的概要設計3.2.1 概要設計在交通局和開發(fā)者雙方認可的《需求分析報告》基礎上,，開發(fā)者進行下——步的工作,。 首先，開發(fā)者需要對軟件系統(tǒng)進行概要設計,，即系統(tǒng)設計,。概要設計需要對軟件系統(tǒng)的設計 進行考慮，包括系統(tǒng)的基本處理流程,、系統(tǒng)的組織結構,、模塊劃分、功能分配,、接口設計,、 運行設計、數(shù)據(jù)結構設計和出錯處理設計等,，為軟件的詳細設計提供基礎,。 3.2.2 編寫概要設計的要求a．一致性 概要設計的要求應該與需求分析報告所描述的需求一致。同時,，概要設計的各項要求之間也應該一致,。 b．合理性 概要設計所提出的設計方法和標準應該是合理的、恰當?shù)摹?/span> c．可追蹤性 對概要設計所提出的各項要求應該可以得到它的清晰的源流,，即在需求分析報告客戶有明確的需求描述,。 d．可行性 根據(jù)概要設計進行詳細設計、操作和維護應該是可行的,。 3.2.3 概要設計報告的編寫者概要設計報告由開發(fā)者根據(jù)需求分析報告的要求進行編寫,。 3.2.4 概要設計和需求分析、詳細設計之間的關系和區(qū)別需求分析不涉及具體的技術實現(xiàn),，而概要設計注重于從宏觀上和框架上來描述采用何種技術手段,、方法來實現(xiàn)這些需求。詳細設計相對概要設計更注重于微觀上和框架內的設計,， 是編碼的依據(jù),。概要設計是指導詳細設計的依據(jù)。 3.2.5 概要設計的評審在軟件概要設計工作完成后,，軟件開發(fā)者應向交通提交《軟件系統(tǒng)概要設計報告》,。在交通局對《概要設計報告》評審通過后，即可進入詳細設計階段,。 3.2.6 概要設計格式《軟件系統(tǒng)概要設計報告》需按一定的格式進行編寫,，具體的《軟件系統(tǒng)概要設計報 告》文檔編寫模板請見附錄B。 3.3 軟件的詳細設計3.3.1 詳細設計在概要設計的基礎上,，開發(fā)者需要進行軟件系統(tǒng)的詳細設計,。在詳細設計中,，描述實 現(xiàn)具體模塊所涉及到的主要算法,、數(shù)據(jù)結構,、類的層次結構及調用關系，需要說明軟件系統(tǒng)各個層次中的每一個程序(每個模塊或子程序)的設計考慮,，以便進行編碼和測試,。應當保證 軟件的需求完全分配給整個軟件。詳細設計應當足夠詳細,，能夠根據(jù)詳細設計報告進行編碼,。 3.3.2 特例如果軟件系統(tǒng)比較簡單，層次較少,，可以不必進行專門的詳細設計,，而和概要設計結合起來。 3.3.3 詳細設計的要求a．一致性 詳細設計的要求應該與需求分析報告所描述的需求,、與概要設計一致,。同時，詳細設計的各項要求之間也應該是一致的,。 b．合理性 詳細設計所提出的設計方法和標準應該是合理的,、恰當?shù)摹?/span> c．可追蹤性 對詳細設計所提出的各項要求應該可以得到它的清晰的源流，即可在需求分析報告,、概要設計報告中有明確的需求描述,。 d．可行性 根據(jù)詳細設計進行編碼、測試,、操作和維護應該是可行的,。 3.3.4 數(shù)據(jù)庫設計如果軟件產品需要使用到數(shù)據(jù)庫，軟件的詳細設計應包括對數(shù)據(jù)庫的設計,。數(shù)據(jù)庫設計應在軟件的需求分析,、概要設計完成之后、詳細設計的其它工作之前進行,。在進行數(shù)據(jù)庫設計時,，應當按照交通局制定的《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》要求進行。 3.3.5 詳細設計的評審在軟件詳細設計完成后,，軟件開發(fā)者應向交通局提交《軟件系統(tǒng)數(shù)據(jù)庫設計報告》和《軟件系統(tǒng)詳細設計報告》,。在交通局對《軟件系統(tǒng)數(shù)據(jù)庫設計報告》、《軟件系統(tǒng)詳細設計報告》評審通過后,，即可進入軟件編碼階段,。 3.3.6 詳細設計格式《軟件系統(tǒng)詳細設計報告》、《軟件系統(tǒng)數(shù)據(jù)庫設計報告》需按一定的格式進行編寫,， 具體的《軟件系統(tǒng)詳細設計報告》文檔編寫模板和《軟件系統(tǒng)數(shù)據(jù)庫設計報告》文檔編寫模 板請見附錄C,、附錄D,。 3.4 軟件的編碼3.4.1 軟件編碼在軟件編碼階段，開發(fā)者根據(jù)《軟件系統(tǒng)詳細設計報告》中對數(shù)據(jù)結構,、算法分析和模塊實現(xiàn)等方面的設計要求,，開始具體的編寫程序工作，分別實現(xiàn)各模塊的功能,，從而實現(xiàn)對目標系統(tǒng)的功能,、性能、接口,、界面等方面的要求,。 3.4.2 軟件編碼的要求a．模塊化編碼 b．代碼可讀性 c．可維護性 d．模塊接口標準化 e．界面風格統(tǒng)一 e．注釋的應用 3.4.3 編碼的評審為了盡早發(fā)現(xiàn)軟件中的障礙，提高軟件產品的質量,，開發(fā)者在編碼的過程中應該強調代碼評審工作,。將代碼評審報告作為文檔的一部分，提交給交通局,。 3.4.4 編程規(guī)范及要求為了提高編程實現(xiàn)的質量,，軟件的程序設計必須遵照國家頒布的相關編程規(guī)范。 主要內容包括：規(guī)范化的程序內部文檔,、數(shù)據(jù)結構的詳細說明,、清晰的語句結構、編碼規(guī)范,。編碼規(guī)范的內容包括命名規(guī)范,、界面規(guī)范、提示及幫助信息規(guī)范,、熱鍵定義等,。 其中數(shù)據(jù)庫部分應遵守《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》的要求。 在軟件編碼的同時應進行單元測試,。 3.5 軟件的測試3.5.1 軟件測試為了盡早發(fā)現(xiàn)軟件產品中的錯誤,，從而達到提高軟件質量、降低軟件維護的費用,，開發(fā)者應在編碼過程中對各個模塊的程序代碼進行單元測試,，系統(tǒng)集成時進行集成測試，系統(tǒng)集成完成后對整個軟件進行系統(tǒng)測試,。單元測試是在軟件開發(fā)過程中針對程序模塊進行正確性檢驗,。集成測試是在單元測試的基礎上，將所有模塊按照設計要求組裝成系統(tǒng)或子系統(tǒng),，對模塊組裝過程和模塊接口進行正確性檢驗,。軟件系統(tǒng)測試不僅是檢測軟件的整體行為表 現(xiàn)，從另一個側面看,，也是對軟件開發(fā)設計的再確認,。進行軟件系統(tǒng)測試工作時,。測試主要包括界面測試、可用性測試,、功能測試,、穩(wěn)定性(強度)測試、性能測試,、強壯性(恢復)測試,、邏輯性測試,、破壞性測試,、安全性測試等。 開發(fā)者針對單元測試,，集成測試,，系統(tǒng)測試分別制定《測試計劃》。集成測試需要根據(jù)需求分析報告和概要設計制作測試用例,，并須經(jīng)過評審,。軟件測試按照《測試計劃》、《需求分析報告》的要求進行,，最后形成《軟件測試報告》,。 3.5.2 測試計劃在軟件編碼開始之前，開發(fā)者應向交通局提交《測試計劃》,，在軟件交付時,，開發(fā)者應向交通局提交《軟件測試報告》，以確保開發(fā)者的軟件得到了充分的測試,。開發(fā)的軟件必須經(jīng)過充分的測試證明其符合設計要求,、運行穩(wěn)定、安全可用方可交付交通局,。 3.6 軟件的交付準備3.6.1 交付清單在軟件測試證明軟件達到要求后,，軟件開發(fā)者應向交通局提交開發(fā)的目標安裝程序、數(shù)據(jù)庫的數(shù)據(jù)字典,、《用戶安裝手冊》,、《用戶使用指南》,、需求報告,、設計報告、測試報告等雙方合同約定的產物,。 《用戶安裝手冊》應詳細介紹安裝軟件對運行環(huán)境的要求,、安裝軟件的定義和內容、在客戶端,、服務器端及中間件的具體安裝步驟,、安裝后的系統(tǒng)配置,。 《用戶使用指南》應包括軟件各項功能的使用流程、操作步驟,、相應業(yè)務介紹,、特殊提示和注意事項等方面的內容,，在需要時還應舉例說明。 3.7 軟件的鑒定驗收3.7.1 軟件的鑒定驗收在軟件開發(fā)完成后,，為了確保軟件是按照需求分析的要求進行開發(fā)的,，保證軟件產品的質量,，需要對軟件產品進行鑒定驗收。在開發(fā)者如期交付軟件后,，由交通局負責確定具體的鑒定驗收日期。 3.7.2 驗收人員由交通局聘請具有一定的分析,、設計,、編程和軟件測試經(jīng)驗的驗收組長和其他專業(yè)人員組成。驗收組設組長一名(可設有副組長),，負責整個驗收的計劃,、組織工作。 3.7.3 驗收具體內容驗收內容應該包括：合法性檢查,、文檔檢查、軟件一致性檢查,、軟件系統(tǒng)測試與測試結果評審等幾項工作,。 合法性檢查檢查軟件開發(fā)工具是否合法、使用的函數(shù)庫,、控件,、組件是否有合法的發(fā)布許可。 文檔檢查檢查開發(fā)者提交的文檔必須齊全,，質量是否過關,。需要開發(fā)者提供的文檔包括： 項目實施計劃； 詳細技術方案,； 軟件需求規(guī)格說明書(STP)(含數(shù)據(jù)字典),； 概要設計說明書(PDD)； 詳細設計說明書(DDD)(含數(shù)據(jù)庫設計說明書),； 軟件測試計劃(STP)(含測試用例),； 軟件測試報告(STR),； 用戶手冊(SUM)(含操作、使用,、維護,、應急處理手冊)； 源程序(SCL)(不可修改的電子文檔),； 項目實施計劃(PIP),； 項目開發(fā)總結(PDS)； 軟件質量保證計劃(SQAP),； 此外,，驗收組可以根據(jù)需要對其它文檔(如軟件配置計劃、項目進展報表,、階段評審報 表等)進行檢查,。 文檔的質量根據(jù)完備性、正確性,、簡明性、可追蹤性,、自說明性,、規(guī)范件等方面進行蹤合評定。 驗收需要對軟件代碼進行檢查,，以確保其符合規(guī)范,，并檢查其一致性。 3.7.4 軟件驗收測試大綱在軟件進行鑒定驗收前,，開發(fā)者需按照一定的格式編寫《軟件驗收測試大綱》,，具體的格式請見附錄E。
3.8 培訓3.8.1 系統(tǒng)應用培訓主要培訓內容包括：系統(tǒng)操作使用,、業(yè)務管理流程,。 培訓對象：應用操作人員。 3.8.2 系統(tǒng)管理的培訓（可選）主要培訓內容包括：系統(tǒng)安裝,、調試,、維護；系統(tǒng)管理,。 培訓對象：系統(tǒng)管理人員,。 開發(fā)者應詳細列出培訓計劃，包括培訓內容,、教材,、時間和人員等。
附錄A 軟件需求分析報告文檔模板 |
||||||||||||||||||||||||||||||
|
|
