【文章內(nèi)容簡介】 變更申請的審批意見 項目經(jīng)理簽字 審批意見： 簽字 日期 客戶簽字 (合同項目 ) 審批意見： 簽字 日期 更改需求文檔 變更后的 需求文檔 輸入名稱，版本，完成日期等信息 更改人簽字 重新評審需求文檔 需求評審小組簽字 評審意見： 簽字 日期 變更結束 項目經(jīng)理簽字 簽字 日期 軟件項目實施里程碑控制 交通局將分四個階段進行把關，召開專家審查會。 （一） 需求分析（結合原型進行審查）確認； （二） 概要設計 +數(shù)據(jù)庫設計； 3 （三） 預驗收（試運行后）； （四） 正式驗收（推廣使用后）。 3. 軟件開發(fā) 合同簽訂以后，項目承擔單位即可組織項目組進行軟件開發(fā)工作。軟件開發(fā)必須嚴格按照軟件工程的要求進行。開發(fā)過程包括開發(fā)者的活動和任務。此過程由軟件需求分析、概要設計、詳細設計、編碼、測試、 驗收、鑒定等活動組成。 軟件的需求分析 需求分析 首先，開發(fā)者和交通局應共同對交通局的應用需求作充分的調研，提交完整的需求分析 報告。在需求分析報告中必須描述的基本問題是：功能、性能、強加于實現(xiàn)的設計限制、屬 性、外部接口。應當避免把設計或項目需求寫入需求分析報告中。它必須說明由軟件獲得的 結果，而不是獲得這些結果的手段。 軟件需求可以用若干種方法來表達，如通過輸入、輸出說明；使用代表性的例子；用規(guī)范化的模型。 開發(fā)者應盡可能地使用模型的方式，因為這是表達復雜需求的精確和有效的方法。比如用統(tǒng)一建模語言（ UML）來描述需求。 編寫需求分析報告的要求 a．無歧義性 對最終產(chǎn)品的每一個特性用某一術語描述；若某一術語在某一特殊的行文中使用時具有多種含義，那么應對該術語的每種含義做出解釋并指出其適用場合。 b．完整性 需求分析報告應該包括全部有意義的需求，無論是關系到功能的、性能的、設計約束的、還是關系到外部接口方面的需求；對所有可能出現(xiàn)的輸入數(shù)據(jù)的響應予以定義，要對合法和非合法的輸入值的響應做出規(guī)定；填寫全部插圖、表、圖示標記等；定義全部術語和度量單位。 c．可驗證性 需求分析報告描述的每一個需求應是可以驗證的。可 以通過一個有限處理過程來檢查軟件產(chǎn)品是否滿足需求。 d．一致性 在需求分析報告中的各個需求的描述不能互相矛盾。 e．可修改性 需求分析報告應具有一個有條不紊、易于使用的內(nèi)容組織；沒有冗余，即同一需求不能在需求分析報告中出現(xiàn)多次。 f．可追蹤性 每一個需求的源流必須清晰，在進一步產(chǎn)生和改變文件編制時，可以方便地引證每一個需求。 g．運行和維護階段的可使用性 需求分析報告必須滿足運行和維護階段的需要。在需求分析報告要寫明功能的來源和目的。 4 需求分析報告的編制者 需求分析報告應由交通局和開發(fā)者雙方共同完成。其中： 交通局負責根據(jù)實際需要提出希望軟件實現(xiàn)的功能；軟件開發(fā)者根據(jù)交通局提出的性能需求，結合軟件開發(fā)編寫需求分析。 需求報告評審 在軟件需求分析工作完成后，軟件開發(fā)者應向交通局提交《軟件需求分析報告》。交通局組織有關人員對需求進行評審，以決定軟件需求是否完善和恰當。評審完成后，就可以進入軟件的設計階段。 需求報告格式 《軟件需求分析報告》需按一定的格式進行編寫，具體的《軟件需求分析報告》文檔編寫模板請見附錄 A。 軟件的概要設計 概要設計 在交通局和開發(fā)者雙方認可的《需求分析報告》基礎上，開發(fā)者進行下 —— 步的工作。 首先，開發(fā)者需要對軟件系統(tǒng)進行概要設計，即系統(tǒng)設計。概要設計需要對軟件系統(tǒng)的設計 進行考慮，包括系統(tǒng)的基本處理流程、系統(tǒng)的組織結構、模塊劃分、功能分配、接口設計、 運行設計、數(shù)據(jù)結構設計和出錯處理設計等，為軟件的詳細設計提供基礎。 編寫概要設計的要求 a．一致性 概要設計的要求應該與需求分析報告所描述的需求一致。同時，概要設計的各項要求之間也應該一致。 b．合理性 概要設計所提出的設計方法和標準應該是合理的、恰當?shù)摹? c．可追蹤性 對概要設計所提出的各項要求應該可以得到它的清晰的源流，即 在需求分析報告客戶有明確的需求描述。 d．可行性 根據(jù)概要設計進行詳細設計、操作和維護應該是可行的。 概要設計報告的編寫者 概要設計報告由開發(fā)者根據(jù)需求分析報告的要求進行編寫。 概要設計和需求分析、詳細設計之間的關系和區(qū)別 需求分析不涉及具體的技術實現(xiàn)，而概要設計注重于從宏觀上和框架上來描述采用何種技術手段、方法來實現(xiàn)這些需求。詳細設計相對概要設計更注重于微觀上和框架內(nèi)的設計， 是編碼的依據(jù)。概要設計是指導詳細設計的依據(jù)。 概要設計的評審 在軟件概要設計工作完成后，軟件開發(fā)者應向交通提交《軟件系統(tǒng)概 要設計報告》。在交通局對《概要設計報告》評審通過后，即可進入詳細設計階段。 概要設計格式 《軟件系統(tǒng)概要設計報告》需按一定的格式進行編寫，具體的《軟件系統(tǒng)概要設計報 告》文檔編寫模板請見附錄 B。 5 軟件的詳細設計 詳細設計 在概要設計的基礎上，開發(fā)者需要進行軟件系統(tǒng)的詳細設計。在詳細設計中，描述實 現(xiàn)具體模塊所涉及到的主要算法、數(shù)據(jù)結構、類的層次結構及調用關系，需要說明軟件系統(tǒng)各個層次中的每一個程序 (每個模塊或子程序 )的設計考慮，以便進行編碼和測試。應當保證 軟件的需求完全分配給整個軟件。詳 細設計應當足夠詳細，能夠根據(jù)詳細設計報告進行編碼。 特例 如果軟件系統(tǒng)比較簡單，層次較少，可以不必進行專門的詳細設計，而和概要設計結合起來。 詳細設計的要求 a．一致性 詳細設計的要求應該與需求分析報告所描述的需求、與概要設計一致。同時，詳細設計的各項要求之間也應該是一致的。 b．合理性 詳細設計所提出的設計方法和標準應該是合理的、恰當?shù)摹? c．可追蹤性 對詳細設計所提出的各項要求應該可以得到它的清晰的源流，即可在需求分析報告、概要設計報告中有明確的需求描述。 d．可行性 根據(jù)詳細設計進行編碼、測試、操作和 維護應該是可行的。 數(shù)據(jù)庫設計 如果軟件產(chǎn)品需要使用到數(shù)據(jù)庫，軟件的詳細設計應包括對數(shù)據(jù)庫的設計。數(shù)據(jù)庫設計應在軟件的需求分析、概要設計完成之后、詳細設計的其它工作之前進行。在進行數(shù)據(jù)庫設計時，應當按照交通局制定的《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》要求進行。 詳細設計的評審 在軟件詳細設計完成后，軟件開發(fā)者應向交通局提交《軟件系統(tǒng)數(shù)據(jù)庫設計報告》和《軟件系統(tǒng)詳細設計報告》。在交通局對《軟件系統(tǒng)數(shù)據(jù)庫設計報告》、《軟件系統(tǒng)詳細設計報告》評審通過后，即可進入軟件編碼階段。 詳細 設計格式 《軟件系統(tǒng)詳細設計報告 》、《軟件系統(tǒng)數(shù)據(jù)庫設計報告》需按一定的格式進行編寫， 具體的《軟件系統(tǒng)詳細設計報告》文檔編寫模板和《軟件系統(tǒng)數(shù)據(jù)庫設計報告》文檔編寫模 板請見附錄 C、附錄 D。 軟件的編碼 軟件編碼 在軟件編碼階段，開發(fā)者根據(jù)《軟件系統(tǒng)詳細設計報告》中對數(shù)據(jù)結構、算法分析和模塊實現(xiàn)等方面的設計要求，開始具體的編寫程序工作，分別實現(xiàn)各模塊的功能，從而實現(xiàn)對目標系統(tǒng)的功能、性能、接口、界面等方面的要求。 軟件編碼的要求 a．模塊化編碼 b．代碼可讀性 6 c．可維護性 d．模塊接口標準化 e．界面風格統(tǒng)一 e．注釋的應 用 編碼的評審 為了盡早發(fā)現(xiàn)軟件中的障礙，提高軟件產(chǎn)品的質量， 開發(fā)者 在編碼的過程中應該強調代碼評審工作。將代碼評審報告作為文檔的一部分，提交給交通局。 編程規(guī)范 及要求 為了提高編程實現(xiàn)的質量，軟件的程序設計必須遵照國家頒布的相關編程規(guī)范。 主要內(nèi)容包括：規(guī)范化的程序內(nèi)部文檔、數(shù)據(jù)結構的詳細說明、清晰的語句結構、編碼規(guī)范。編碼規(guī)范的內(nèi)容包括命名規(guī)范、界面規(guī)范、提示及幫助信息規(guī)范、熱鍵定義等。 其中數(shù)據(jù)庫部分應遵守《 南京市交通局信息化數(shù)據(jù)庫建設規(guī)范 》的要求。 在軟件編碼的同時應進行單元測試。 軟件的測試 軟件測 試 為了盡早發(fā)現(xiàn)軟件產(chǎn)品中的錯誤，從而達到提高軟件質量、降低軟件維護的費用，開發(fā)者應在編碼過程中對各個模塊的程序代碼進行單元測試，系統(tǒng)集成時進行集成測試，系統(tǒng)集成完成后對整個軟件進行系統(tǒng)測試。單元測試是在軟件開發(fā)過程中針對程序模塊進行正確性檢驗。集成測試是在單元測試的基礎上，將所有模塊按照設計要求組裝成系統(tǒng)或子系統(tǒng)，對模塊組裝過程和模塊接口進行正確性檢驗。軟件系統(tǒng)測試不僅是檢測軟件的整體行為表