1、引言 1目的 一項計算機軟件的籌劃、研制及實現，構成一個軟件開發(fā)項目。一個軟件開發(fā) 項目的進行，一般需要 在人力和自動化資源等方面作重大的投資。為了保證項 目開發(fā)的成功，最經濟地花費這些投資，并且便 于運行和維護，在開發(fā)工作的 每一階段，都需要編制二定的文件。這些文件連同計算機程序及數據一起，構 成為計算機軟件。文件是計算機軟件中不可缺少的組成部分，它的作用是： a 作為開發(fā)人員在一定階段內的工作成果和結束標志； b.向管理人員提供軟件開發(fā)過程中的進展和情況， 把軟件開發(fā)過程中的一些 不可見的”事物轉 換成 可見的”文字資料。以便管理人員在各個階段檢查開發(fā)計 劃的實施進展，使之能夠判斷原定目標

2、是 否已達到，還將繼續(xù)耗用資源的種類 和數量； C 記錄開發(fā)過程中的技術信息，便于協(xié)調以后的軟件開發(fā)、使用和修改； d 提供對軟件的有關運行、維護和培訓的信息，便于管理人員、開發(fā)人員、 操作人員和用戶之間相互了解彼此的工作； e.向潛在用戶報導軟件的功能和性能， 使他們能判定該軟件能否服務于自己 的需要。 換言之，本指南認為：文件的編制必須適應計算機軟件整個生存周期的需要。 計算機軟件所包含的文件有兩類：一類是開發(fā)過程中填寫的各種圖表，可稱 之為工作表格；另一類 則是應編制的技術資料或技術管理資料， 可稱之為文件。 本指南規(guī)定軟件文件的編制形式，并提供對這些規(guī)定的解釋。本指南的目的是 使得所編

3、制的軟件文件確實能夠起到軟件文件應該發(fā)揮的作用。 2范圍 本指南是一份指導性文件。本指甫建議，在一項計算機軟件的開發(fā)過程中, 般地說，應該產生十四 種文件。這十四種文件是： 可行性研究報告； 項目開發(fā)計劃； 軟件需求說明書； 數據要求說明書； 概要設計說明書； 詳細設計說明書； 數據庫設計說明書； 用戶手冊； 操作手冊； 模塊開發(fā)卷宗； 測試計劃； 測試分析報告； 開發(fā)進度月報； 項目開發(fā)總結報告。 本指南將給出開發(fā)過程中建議產生的這十四種文件的編制指導， 同時，本指南 也是這十四種文件的 編寫質量的檢驗準則。但是，本指南并未涉及軟件開發(fā)過 程中如何填寫工作表格的問題。 一般地說，一個軟件總是

4、一個計算機系統(tǒng)（包括硬件、固件和軟件）的組成部 分。鑒于計算機系統(tǒng)的 多樣性，本指南一般不涉及整個系統(tǒng)開發(fā)中的文件編制 問題，本指南僅僅是軟件開發(fā)過程中的文件編制指南。 3 文件的使用者 對于使用文件的人員而言，他們所關心的文件的種類，隨他們所承擔的工作 而異。 管理人員：可行性研究報告， 項目開發(fā)計劃， 模塊開發(fā)卷宗， 開發(fā)進度月報， 項目開發(fā)總結報告； 開發(fā)人員：可行性研究報告， 項目開發(fā)計劃， 軟件需求說明書， 數據要求說明書， 概要設計說明書， 詳細設計說明書， 數據庫設計說明書， 測試計劃， 測試分析報告； 維護人員：設計說明書， 測試分析報告， 模塊開發(fā)卷宗； 用戶：用戶手冊， 操

5、作手冊。 盡管本指南提出了在軟件開發(fā)中文件編制的要求，但并不意味著這些文件都 必須交給用戶。一項軟件的用戶應該得到的文件的種類由供應者與用戶之間簽訂 的合同規(guī)定。 第一篇 文件的編制指導 4 軟件生存周期與各種文件的編制 一項計算機軟件，從出現一個構思之日起，經過這項軟件開發(fā)成功投入使用， 直到最后決定停止使 用，并被另一一項軟件代替之時止，被認為是該軟件的一 個生存周期。 一般地說這個軟件生存周期可以分成以下六個階段： 可行性與計劃 研究階段 需求分析階段 設計階段 實現階段 測試階段 運行與維護階段 在可行性研究與計劃階段內， 要確定該軟件的開發(fā)目標和總的要求， 要進行可 行性分析、投資一

6、收益分析、制訂開發(fā)計劃，并完成應編制的文件。 在需求分析階段內， 由系統(tǒng)分析人員對被設計的系統(tǒng)進行系統(tǒng)分析， 確定對該 軟件的各項功能、 性能需求和設計約束， 確定對文件編制的要求， 作為本階段工 作的結果， 一般地說，軟件需求說明書、 數據要求說明書和初步的用戶手冊應該 編寫出來。 在設計階段內，系統(tǒng)設計人員和程序設計人員應該在反復理解軟件需求的基礎 上，提出多個設計， 分析每個設計能履行的功能并進行相互比較， 最后確定一個 設計，包括該軟件的結構、模塊的劃分、功能的分配以及處理流程。在被設計系 統(tǒng)比較復雜的情況下，設計階段應分解成概要設計階段和詳細設計階段兩個步 驟。在一般情況下，應完成的

7、文件包括：概要設計說明書、詳細設計說明書和測 試計劃初稿。 在實現階段內，要完成源程序的編碼、編譯（或匯編）和排錯調試得到無語法 錯的程序清單，要開始編寫模塊開發(fā)卷宗，并且要完成用戶手冊、操作手冊等面 向用戶的文件的編寫工作，還要完成測試計劃的編制。 在測試階段，該程序將被全面地測試，已編制的文件將被檢查審閱。一般要完 成模塊開發(fā)卷宗和測試分析報告， 作為開發(fā)工作的結束，所生產的程序、文件以 及開發(fā)工作本身將逐項被評價，最后寫出項目開發(fā)總結報告。 在整個開發(fā)過程中（即前五個階段中），開發(fā)集體要按月編寫開發(fā)進度月報。 在運行和維護階段，軟件將在運行使用中不斷地被維護， 根據新提出的需求進 行必要

8、而且可能的擴充和刪改。 對于一項軟件而言，其生存周期各階段與各種文件編寫工作的關系可見表互， 其中有些文件的編寫工作可能要在若干個階段中延續(xù)進行。 表1軟件生存周期各階段中的文件編制 階段 文件 可行性研究 與計劃階段 需求分析階段 設計 階段 現段 實階 測試 階段 運行與維 護階段 數據需求說明書 項目開發(fā)計劃 軟件需求說明書 數據需求說明書 測試計劃 概要設計說明書 詳細設計說明書 數據庫設計說明 書 模塊開發(fā)巻來 用戶手冊 操作手冊 測試分析報告 開發(fā)進度月報 項目開發(fā)總結 5 文件編制中的考慮因素 文件編制是一個不斷努力的工作過程。 是一個從形成最初輪廓， 經反復檢查和 修改，直到程

9、序和文件正式交付使用的完整過程。 其中每一步都要求工作人員做 出很大努力。 要保證文件編制的質量， 要體現每個開發(fā)項目的特點， 也要注意不 要花太多的人力。為此，編制中要考慮如下各項因素。 5 1 文件的讀者 每一種文件都具有特定的讀者。這些讀者包括個人或小組、軟件開發(fā)單位的 成員或社會上的公眾、 從事軟件工作的技術人員、 管理人員或領導干部。 他們期 待著使用這些文件的內容來進行工作，例如設計、編寫程序、測試、使用、維護 或進行計劃管理。 因此，這些文件的作者必須了解自己的讀者， 這些文件的編寫 必須注意適應自己的特定讀者的水平、特點和要求。 5 2 重復性 本指南第二篇中將列出的這十四種文

10、件的內容要求中，顯然存在某些重復。 較明顯的重復有兩類。 引言是每一種文件都要包含的內容， 以向讀者提供總的梗 概。第二類明顯的重復是各種文件中的說明部分， 如對功能性能的說明、 對輸入 和輸出的描述、 系統(tǒng)中包含的設備等。 這是為了方便每種文件各自的讀者， 每種 產品文件應該自成體系， 盡量避免讀一種文件時又不得不去參考另一種文件。 當 然，在每一種文件里，有關引言、說明等同其他文件相重復的部分，在行文上、 在所用的術語上、 在詳細的程度上， 還是應該有一些差別， 以適應各種文件的不 同讀者的需要。 5 3 靈活性 鑒于軟件開發(fā)是具有創(chuàng)造性的腦力勞動，也鑒于不同軟件在規(guī)模上和復雜程 度上差別

11、極大， 本指南認為在文件編制工作中應允許一定的靈活性。 這種靈活性 表現在如下各款。 5 31 應編制的文件種類 盡管本指南認為在一般情況下， 一項軟件的開發(fā)過程中， 應產生的文件有十四 種，然而針對一項具體的軟件開發(fā)項目， 有時不必編制這么多的文件， 可以把幾 種文件合并成一種。一般地說，當項目的規(guī)模、復雜性和成敗風險增大時，文件 編制的范圍、管理手續(xù)和詳細程度將隨之增加。反之，則可適當減少。為了恰當 地掌握這種靈活性，本指南要求貫徹分工負責的原則，這意味著： a: 一個軟件開發(fā)單位的領導機構應該根據本單位經營承包的應用軟件的專業(yè) 領域和本單位的管理能力， 制定一個對文件編制要求的實施規(guī)定，

12、 主要是： 在不 同的條件下，應該形成哪些文件？這些文件的詳細程度？該開發(fā)單位的每一個項 目負責人，必須認真執(zhí)行這個實施規(guī)定。這種規(guī)定的兩個例子可嘆 本指南的附 錄 o （參考件）； b對于一個具體的應用軟件項目，項目負責人應根據上述實施規(guī)定，確定一 個文件編制計劃，主 中包括 : （1）應該編制哪幾種文件，詳細程度如何？ （2）各個文件的編制負責人和進度要求； （3）審查、批準的負責人和時間進度安排； （4）在開發(fā)時期內，各文件的維護、修改和管理的負責人，以及批準手續(xù)。 每項工作必須落實到人。 這個文件編制計劃是整個開發(fā)計劃的重要組成部分； C 有關的設計人員則必須嚴格執(zhí)行這個文件編制計劃。

13、 5 32 文件的詳細程度 從同一份提綱起草的文件的篇幅大小往往不同， 可以少到幾頁， 也可以長達幾 百頁。對于這種差別本指南是允許的。 此詳細程度取決于任務的規(guī)模、 復雜性和 項目負責人對該軟件的開發(fā)過程及運行環(huán)與所需要的詳細程度的判斷。 5 33 文件的擴展 當被開發(fā)系統(tǒng)的規(guī)模非常大 （例如源碼超過一百萬行） 時，一種文件可以分成 幾卷編寫，可以按其。 每一個系統(tǒng)分別編制，也可以按內容劃分成多卷，例如： 項目開發(fā)計劃可能包括：質量保證計劃， 配置管理計劃， 用戶培訓計劃， 安裝實施計劃； 系統(tǒng)設計說明書可分寫成：系統(tǒng)設計說明書， 子系統(tǒng)設計說明書； 程序設計說明書可分寫成：程序設計說明書，

14、 接口設計說明書， 版本說明； 操作手冊可分寫成：操作手冊， 安裝實施過程； 測試計劃可分寫成：測試計劃， 測試設計說明， 測試規(guī)程， 測試用例； 測試分析報告可分寫成：綜合測試報告， 驗收測試報告； 項目開發(fā)總結報告亦可分寫成項目開發(fā)總結報告和資源環(huán)境統(tǒng)計。 5 34 節(jié)的擴張與縮并 在有些文件中， 可以使用本指南所提供的章、 條標題， 但在條內又存在一系列 需要分別討論的因素 本指南認為，所有的條都可以擴展，可以進一步細分，以 適應實際需要。反之，如果章條中的有些細節(jié)； 非必需，也可以根據實際情況 縮并。此時章條的編號應相應地改變。 5 35 程序設計的表現形式 本指南對于程序的設計表現形

15、式并未作出規(guī)定或限制，可以使用流程圖的形 式、判定表的形式， 1 可以使用其他表現形式，如程序設計語言（ PDL ）、問題 分析圖（ PAD ）等。 5 36 文件的表現形式 本指南對于文件的表現形式亦未作出規(guī)定或限制， 可以使用自然語言， 也可以 使用形式化語言。 5 37 文件的其他種類 當本指南中規(guī)定的文件種類尚不能滿足某些應用部門的特殊需要時， 他們可以 建立一些特殊的文件種類要求，例如軟件質量保證計劃、軟件配置管理計劃等， 這些要求可以包含在本單位的文件編制實施規(guī)定中。 6 文件編制的管理工作 文件編制工作必須有管理工作的配合，才能使所編制的文件真正發(fā)揮它的作 用。文件的編制工作實際

16、上貫穿于一項軟件的整個開發(fā)過程， 因此，對文件的管 理必須貫穿于整個開發(fā)過程。在開發(fā)過程中必須進行的管理工作是以下四條。 6 1 文件的形成 開發(fā)集體中的每個成員，尤其是項目負責人，應該認識到：文件是軟件產品 的必不可少的組成部分； 在軟件開發(fā)過程的各個階段中， 必須按照規(guī)定及時地完 成各種產品文件的編寫工作； 必須把在一個開發(fā)步驟中作出的決定和取得的結果 及時地寫入文件； 開發(fā)集體必須及時地對這些文件進行嚴格的評審； 這些文件的 形成是各個階段開發(fā)工作正式完成的標志。 這些文件上必須有編寫者、 評審者和 批準者的簽字，必須有編寫、評審完成的日期和批準的日期。 6 2 文件的分類與標識 在軟件

17、開發(fā)的過程中，產生的文件是很多的，為了便于保存、查找、使用和 修改，應該對文件按層次地加以分類組織。 一個軟件開發(fā)單位應該建立一個對本 單位文件的標識方法， 使文件的每一頁都具有明確的標識。 例如可以按如下四個 層次對文件加以分類和標識。 a 文件所屬的項目的標識； b 文件種類的標識； C .同一種文件的不同版本號； d .頁號。 此外，對每種文件還應根據項目的性質，劃定它們各自的保密級別，確定他 們各自的發(fā)行范圍。 6.3 文件的控制 在一項軟件的開發(fā)過程中， 隨著程序的逐步形成和逐步修改， 各種文件亦在不 斷地產生、不斷地修改或補充。因此，必須加以周密的控制，以保持文件與程序 產品的一致

18、性，保持各種文件之間的一致性和文件的安全性。這種控制表現為： a. 就從事一項軟件開發(fā)工作的開發(fā)集體而言，應設置一位專職的文件管理人 員（接口管理工程師或文件管理員）；在開發(fā)集體中，應該集中保管本項目現有 全部文件的主文本兩套，由該文件管理人員負責保管； b. 每一份提交給文件管理人員的文件都必須具有編寫人、審核人和批準人的 簽字； C這兩套主文本的內容必須完全一致； 其中有一套是可供出借的，另一套是 絕對不能出借的，以免發(fā)生萬一；可出借的主文本在出借時必須辦理出借手續(xù)， 歸還時辦理注銷出借手續(xù)； d. 開發(fā)集體中的工作人員可以根據工作的需要， 在本項目的開發(fā)過程中持有 一些文件， 即所謂個人

19、文件， 包括為使他完成他承擔的任務所需要的文件， 以及 他在完成任務過程中所編制的文件； 但這種個人文件必須是主文本的復制品， 必 須同主文本完全一致，若要修改，必須首先修改主文本； e. 不同開發(fā)人員所擁有的個人文件通常是主文本的各種子集；所謂子集是指 把主文本的各個部分根據承擔不同任務的人員或部門的工作需要加以復制、 組裝 而成的若干個文件的集合； 文件管理人員。 應該列出一份不同子集的分發(fā)對象的 清單，按照清單及時把文件分發(fā)給有關人員或部門； f. 一份文件如果已經被另一份新的文件所代替，則原文件應該被注銷；文件 管理人中要隨時整理主文本， 及時反映出文件的變化和增加情況， 及時分發(fā)文件

20、； g. 當一個項目的開發(fā)工作臨近結束時， 文件管理人員應逐個收回開發(fā)集體內 每個成員的個人文 件，并檢查這些個人文件的內容；經驗表明，這些個人文件 往往可能比主文本更詳細，或同主文本的內容 有所不同，必須認真監(jiān)督有關人 員進行修改，使主文本能真正反映實際的開發(fā)結果。 6 4 文件的修改管理 在一個項目的開發(fā)過程中的任何時刻，開發(fā)集體內的所有成員都可能對開發(fā) 工作的已有成果 文件，提出進行修改的要求。提出修改要求的理由可能是 各種各樣的，進行修改而引起的影響可能很小， 也可能會牽涉到本項目的很多 方面。因此，修改活動的進行必須謹慎，必須對修改活動的進行加以管理，必 須執(zhí)行修改活動的規(guī)程，使整個

21、修改活動有控制地進行。 修改活動可分如下五個步驟進行： a 提議開發(fā)集體中的任何一個成員都可以向項目負責人提出修改建議， 為此 應該填寫一份修 改建議表，說明修改的內容、所修改的文件和部位、以及修改 理由； b評議由項目負責人或項目負責人指定的人員對該修改建議進行評議，包括 審查該項修改的 必要性、確定這一修改的影響范圍、研究進行修改的方法、步 驟和實施計劃； c審核一般由項目負責人進行審核，包括核實修改的自的和要求、核實修改 活動將帶來的影 響、審核修改活動計劃是否可行； d 批準在一般情況下，批準權屬于該開發(fā)單位的部門負責人；在批準時，主 要是決斷修改工作 中各項活動的先后順序及各自的完成

22、日期，以保證整個開發(fā) 工作按原定計劃日期完成； e.實施由項目負責人按照已批準的修改活動計劃，安排各項修改活動的負責 人員進行修改，建 立修改記錄、產生新的文件以取代原有文件、最后把文件交 文件管理人員歸檔，并分發(fā)給有關的持有者。 第二篇 各種文件的內容要求 本篇將對引言中提到的十四種文件提供內容要求， 作為文件編制的技術標準。 7 可行性研究報告 可行性研究報告的編寫目的是：說明該軟件開發(fā)項目的實現在技術、經濟和 社會條件方面的可行 性；評述為了合理地達到開發(fā)目標而可能選擇的各種方案； 說明并論證所選定的方案。 可行性研究報告的編寫內容要求如下： 7 1 引言 7 1C 1 編寫目的 7 1

23、 2 背景 7 1 3 定義 7 1 4 參考資料 7 7 2 可行性研究的前提 7 2 1 要求 7 2 2目標 7 2 3 條件、假定和限制 7 2 4 進行可行性研究的方法 7 2 5 評價尺度 7 3 對現有系統(tǒng)的分析 7 3 1 數據流程和處理流程 732 工作負荷 733 費用開支 7 3 4 人員 7 3 5 設備 736 局限性 74 所建議的系統(tǒng) 741 對所建議系統(tǒng)的說明 7 4 2 數據流程和處理流程 743 改進之處 7 4 4 影響 7 4 4 1 對設備的影響 7 4 4 2 對軟件的影響 7 4 4 3 對用戶單位機構的影響 7444 對系統(tǒng)運行的影響 7445

24、對開發(fā)的影響 74，46 對地點和設施的影響 7 4 4 7 對經費開支的影響 7 4 5 局限性 746 技術條件方面的可行性 75 可選擇的其他系統(tǒng)方案 751 可選擇的系統(tǒng)方案 1 752 可選擇的系統(tǒng)方案 2 76 投資及收益分析 761 支出 7611 基本建設投資 7612 其他一次性支出 7613 非一次性支出 7 6 2 收益 7 6， 2 1 一次性收益 7 6 2 2 非一次性收益 7 6 2 3 不可定量的收益 763 收益投資比 764 投資回收周期 765 敏感性分析 77 社會條件方面的可行性 771 法律方面的可行性 772 使用方面的可行性 78 結論 8 項目

25、開發(fā)計劃 編制項目開發(fā)計劃的目的是用文件的形式， 把對于在開發(fā)過程中各項工作的負 責人員、開發(fā)進度、 所需經費預算、所需軟、硬件條件等問題作出的安排記載 下來，以便根據本計劃開展和檢查本項目的開 發(fā)工作。編制內容要求如下： 8 1 引言 8 1 1 編寫目的 8 1 2 背景 8 1 3 定義 8 1 4 參考資料 8 2 項目概述 8 2 1 作內容 8 2 2 主要參加人員 8 2 3 產品及成果 8 2 3 1 程序 8 2 32 文件 8 2 33 服務 8 2 34 非移交產品 8 2 4 驗收標準 8 25 完成項目的最遲期限 8 2 6 本計劃的審查者與批準者 8 3 實施總計劃

26、 8 3 1 工作任務的分解 8 3 2 接口人員 8 3 3 進度 8 3 4 預算 8 3 5 關鍵問題 8 4 支持條件 8 4 1 計算機系統(tǒng)支持 8 4 2 需要用戶承擔的工作 8 4 3 需由外單位提供的條件 85 專題計劃要點 9 軟件需求說明書 軟件需求說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定 有一個共同的理解， 使之成為整個開發(fā)工作的基礎。編制軟件需求說明書的內 容要求如下： 9 1引 言 9 1 1 編寫目的 9 1 2 背景 9 1 3 定義 9 1 4 參考資料 9 2 任務概述 9 2 1 目標 9 2 2 用戶的特點 9 2 3 假定與約束 9 3

27、 需求規(guī)定 9 3 1 對功能的規(guī)定 9 3 2 對性能的規(guī)定 9 3 21 精度 9 3 22 時間特性耍求 9 3 23 靈活性 9 3 3 輸入輸出要求 9 3 4 數據管理能力要求 9 3 5 故障處理要求 9 3 6 其他專門要求 9 4 運行環(huán)境規(guī)定 9 4 1 設備 9 4 2 支持軟件 9 4 3 接口 9 4 4 控制 10 數據要求說明書 數據 要求說明書的編制目的是為了向整個開發(fā)時期提供關于被處理數據的描 述和數據采集要求的 技術信息。編制數據要求說明書的內容要求如下： 10 1引 言 10 1 1 編寫目的 10 1 2 背景 10 1 3 定義 10 1 4 參考資料

28、 10 2數 據的邏輯描述 10 2 1 靜態(tài)數據 10 2 2 動態(tài)輸入數據 10 2 3 動態(tài)輸出數據 10 2 4 內部生成數據 10 2 5 數據約定 10 3數 據的采集 10 3 1 要求和范圍 10 3 2 輸入的承擔者 10 3 3 處理 10 3 4 影響。 11 概要設計說明書 概要設計說明書又可稱系統(tǒng)設計說明書， 這里所說的系統(tǒng)是指程序系統(tǒng)。 編制 的目的是說明對程序 系統(tǒng)的設計考慮，包括程序系統(tǒng)的基本處。流程、程序系 統(tǒng)的組織結構、模塊劃分、功能分配、接口設計。 運行設計、數據結構設計和 出錯處理設計等，為程序的詳細設計提供基礎。編制概要設計說明書的內容 要 求如下 ：

29、 11 1引 言 11 1 1 編寫目的 11 1 2 背景 11 1 3 定義 11 1 4 參考資料 11 2 總體設計 11 2 1 需求規(guī)定 11 2 2 運行環(huán)境 11 2 3 基本設計概念和處理流程 112 4 結構 112 5 功能需求與程序的關系 112 6 人工處理過程 1127 尚未解決的問題 113 接口設計 1131 用戶接口 1132 外部接口 1133 內部接口 114 運行設計 114 1 運行模塊組合 1142 運行控制 114 3 運行時間 115 系統(tǒng)論據結構設計 1151 邏輯結構設計要點 1152 物理結構設計要點 1153 數據結構與程序的關系 11

30、6 系統(tǒng)出錯處理設計 1161 出錯信息 1162 補救措施 116 3 系統(tǒng)維護設計 12 詳細設計說明書 詳細設計說明書又可稱程序設計說明書。 編制目的是說明一個軟件系統(tǒng)各個層 次中的每一個程序 （每個模塊或子程序）的設計考慮，如果一個軟件系統(tǒng)比較 簡單，層次很少，本文件可以不單獨編寫，有關 內容合并入概要設計說明書。 對詳細設計說明書的內容要求如下： 121 引言 1211 編寫目的 1212 背景 1213 定義 1214 參考資料 122 程序系統(tǒng)的組織結構 12 3程序 1（標識符）設計說明 1231 程序描述 123 2 功能 123 3 性能 1234 輸入項 1235 輸出項

31、 1236 算法 1237 流程邏輯 123 8 接口 1239 存儲分配 123 10 注釋設計 12311 限制條件 123 12 測試計劃 12313 尚未解決的問題 124程序 2（標識符）設計說明 13 數據庫設計說明書 數據庫設計說明書的編制目的是對于設計中的數據庫的所有標識、邏輯結構 和物理結構作出具體的設計規(guī)定。其內容要求如下： 13 1 引言 13 1 1 編寫目的 13 1 2 背景 13 1 3 定義 13 1 4 參考資料 13 2 外部設計 13 2 1 標識符和狀態(tài) 13 2 2 使用它的程序 13 2 3 約定 13 2 4 專門指導 13 2 5 支持軟件 13

32、 3 結構設計 13 3 1 概念結構設計 13 3 2 邏輯結構設計 13 3 3 物理結構設計 13 4 運用設計 13 4 1 數據字典設計 1342 安全保密設計 14 用戶手冊 用戶手冊的編制是要使用非專門術語的語言， 充分地描述該軟件系統(tǒng)所具有的 功能及基本的使用方法。 使用戶（或潛在用戶） 通過本手冊能夠了解該軟件的用 途，并且能夠確定在什么情況下，如何使用它。具體的內容要求如下： 14 1引 言 14 1 1 編寫目的 14 1 2 背景 14 1 3 定義 14 1 4 參考資料 14 2 用途 14 2 1 功能 14 2 2 性能 14 2 21 精度 14 2 22 時

33、間特性 14 2 23 靈活性 14 2 3 安全保密 14 3 運行環(huán)境 14 3 1 硬設備 14 3 2 支持軟件 14 3 3 數據結構 14 4 使用過程 14 4 1 安裝與初始化 14 4 2 輸入 14 4 21 輸入數據的現實背景 14 4 22 輸入格式 14 4 23 輸入舉例 14 4 3 輸出 14 4 31 輸出數據的現實背景 14 4 32 輸出格式 14 4 33 輸出舉例 14 4 4 文卷查詢 14 4 5 出錯處理與恢復 14 4 6 終端操作 15 操作手冊 操作手冊的編制是為了向操作人員提供該軟件每一個運行的具體過程和有關 知識，包括操作方法的細節(jié)。具

34、體的內容要求如下： 151 引言 1511 編寫目的 1512 背景 15 13 定義 15 14 參考資料 15 2 軟件概述 1521 軟件的結構 15 22 程序表 1523 文卷表 153 安裝與初始化 154 運行說明 15 41 運行表 1542 運行步驟 1543運行 1（標識符）說明 15431 運行控制 15432 操作信息 15433 輸入一輸出文卷 15434 輸出文段 15435 輸出文段的復制 15436 啟動恢復過程 1544運行 2（標識符）說明 155 非常現過程 15 6 遠程操作 16 模塊開發(fā)卷宗 模塊開發(fā)卷宗是在模塊開發(fā)過程中逐步編寫出來的， 每完成一個

35、模塊或一組密 切相關的模塊的復審時編寫一份，應該把所有的模塊開發(fā)卷宗匯集在一起。 編寫 的目的是記錄和匯總低層次開發(fā)的進度和結果，以便于對整個模塊開發(fā)工作的管 理和復審，并為將來的維護提供非常有用的技術信息。具體的內容要求如下： 16.1標題 16. 2模塊開發(fā)情況表（見下表） 模塊開發(fā)情況表 模塊標識符 模塊的描述性名稱 代碼設計 計劃開始日期 實馬幵始日期 計劃完咸日期 實際完成日期 模塊測試 計劃開始日期 實際開始日期 計劃完成日期1 實你完感日期 組叢測試 計劃開始日期 實際開始日期 計劃完成日期 實際完成日期 代碼復查日期噬字 源代碼行數 預計 實際 目標模塊大小 預計 實際 模塊標

36、識符 項目負責人批誰日期宇 16. 3功能說明 16 . 4設計說明 16. 5源代碼清單 16. 6測試說明 16. 7復審的結論 17 測試計劃 這里所說的測試，主要是指整個程序系統(tǒng)的組裝測試和確認測試。本文件的編 制是為了提供一個對該軟件的測試計劃， 包括對每項測試活動的內容、 進度安排、 設計考慮、測試數據的整理方法及評價準則。具體的內容要求如下： 17 1引 言 17 1 1 編寫目的 17 1 2 背景 17 1 3 定義 17 1 4 參考資料 17 2 計劃 17 2 1 軟件說明 17 2 2 測試內容 17 2 3 測試 1 （標識符） 17 2 31 進度安排 17 2

37、32 條件 17 2 33 測試資料 17 2 34 測試培訓 17 2 4 測試 2 （標識符） 173 測試設計說明 17 3 1 測試l （標識符） 17 3 1 1 控制 17 3 1 2 輸入 17 3 1 3 輸出 17 3 1 4 過程 17 3 2 測試 2（標識符） 174 評價準則 17 4 1 范圍 17 4 2 數據整理 17 4 3 尺度 18 測試分析報告 測試分析報告的編寫是為了把組裝測試和確認測試的結果、發(fā)現及分析寫成文 件加以記載，具體的內容要求如下： 18 1 引言 18 1 1 編寫目的 18 1 2 背景 18 1 3 定義 18 1 4 參考資料 18

38、 2 測試概要 18 3 測試結果及發(fā)現 18 3 1 測試 1 （標識符） 18 3 2 測試 2 （標識符） 18 4 對軟件功能的結論 18 4 1 功能 1 （標識符） 18 4 11 能力 18 4 12 限制 18 4 2 功能 2 （標識符） 18 5 分析摘要 18 5 1 能力 18 5 2 缺陷和限制 18 5 3 建議 18 5 4 評價 18 6 測試資源消耗 19 開發(fā)進度月報 開發(fā)進度月報的編制目的是及時向有關管理部門匯報項目開發(fā)的進展和情 況，以便及時發(fā)現和處 理開發(fā)過程中出現的問題。一般地，開發(fā)進度月報是以 項目組為單位每月編寫的。如果被開發(fā)的軟件系 統(tǒng)規(guī)模比較

39、大，整個工程項目 被劃分給若干個分項目組承擔，開發(fā)進度月報將以分項目組為單位按月編 寫 具體的內容要求如下： 19 1 標題 192 工程進度與狀態(tài) 19 2 1 進度 19 2 2 狀態(tài) 19 3 資源耗用與狀態(tài) 19 3 1 資源耗用 19 3 11 工時 19 3 12 機時 19 3 2 狀態(tài) 19 4 經費支出與狀態(tài) 19 4 1 經費支出 19 4 11 支持性費用 19 4 12 設備購置費 19 4 2 狀態(tài) 19 5 下個月的工作計劃 19 6 建議 20 項目開發(fā)總結報告 項目開發(fā)總結報告的編制是為了總結本項目開發(fā)工作的經驗，說明實際取得 的開發(fā)結果以及對整個開發(fā)工作的各個

40、方面的評價。具體的內容要求如下： 20 1 引言 20 1 1 編寫目的 20 1 2 背景 20 1 3 定義 20 1 4 參考資料 20 2 1 產品 20 2 實際開發(fā)結果 20 2 2 主要功能和性能 20 2 3 基本流程 20 2 4 進度 20 2 5 費用 20 3 開發(fā)工作評價 20 3 1 對生產效率的評價 20 3 2 對產品質量的評價 20 3 3 對技術方法的評價 2034 出錯原因的分析 204 經驗與教訓 附錄 A 可行性研究報告的編寫提示 （參考件） A 1 引言 A11 編寫目的 說明編寫本可行性研究報告的目的，指出預期的讀者。 A12 背景 說明： a 所

41、建議開發(fā)的軟件系統(tǒng)的名稱； b 本項目的任務提出者、開發(fā)者、用戶及實現該軟件的計算中心或計算機 網絡； C 該軟件系統(tǒng)同其他系統(tǒng)或其他機構的基本的相互來往關系。 A13 定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。 A14 參考資料 列出用得著的參考資料，如： a .本項目的經核準的計劃任務書或合同、上級機關的批文； b .屬于本項目的其他已發(fā)表的文件； C .本文件中各處引用的文件、資料，包括所需用到的軟件開發(fā)標準。| 列出這些文件資料的標題、文件編號、發(fā)表日期和出版單位，說明能夠得到 這些文件資料的來源。 A. 2 可行性研究的前提 說明對所建議的開發(fā)項目進行可行性研究

42、的前提，如要求、目標、假定、限 制等。 A. 2. 1 要求 說明對所建議開發(fā)的軟件的基本要求，如： a .功能； b .性能； C 輸出如報告、文件或數據，對每項輸出要說明其特征，如用途、產生頻度、 接口以及分發(fā)對象； d 輸入說明系統(tǒng)的輸入，包括數據的來源、類型、數量、數據的組織以及提 供的頻度； e 處理流程和數據流程用圖表的方式表示出最基本的數據流程和處理流程， 并輔之以敘述； f.在安全與保密方面的要求； g .同本系統(tǒng)相連接的其他系統(tǒng)； h .完成期限。 A. 2. 2 目標 說明所建議系統(tǒng)的主要開發(fā)目標，如： a .人力與設備費用的減少； b .處理速度的提高； C .控制精度或

43、生產能力的提高； d .管理信息服務的改進； e .自動決策系統(tǒng)的改進； f.人員利用率的改進。 A. 2. 3 條件、假定和限制 說明對這項開發(fā)中給出的條件、假定和所受到的限制，如： a .所建議系統(tǒng)的運行壽命的最小值； b .進行系統(tǒng)方案選擇比較的時間； c. 經費、投資方面的來源和限制； d .法律和政策方面的限制； e .硬件、軟件、運行環(huán)境和開發(fā)環(huán)境方面的條件和限制； f. 可利用的信息和資源； g. 系統(tǒng)投入使用的最晚時間。 A24 進行可行性研究的方法 說明這項可行性研究將是如何進行的，所建議的系統(tǒng)將是如何評價的。摘要 說明所使用的基本方法 和策略，如調查、加權、確定模型、建立基

44、準點或仿真 等。 A 2 5 評價尺度 說明對系統(tǒng)進行評價時所使用的主要尺度，如費用的多少、各項功能的優(yōu)先 次序、開發(fā)時間的長短 及使用中的難易程度。 A3 對現有系統(tǒng)的分析 這里的現有系統(tǒng)是指當前實際使用的系統(tǒng)，這個系統(tǒng)可能是計算機系統(tǒng)，也 可能是一個機械系統(tǒng)甚 至是一個人工系統(tǒng)。 分析現有系統(tǒng)的目的是為了進一步闡明建議中的開發(fā)新系統(tǒng)或修改現有系統(tǒng) 的必要性。 A31 處理流程和數據流程 說明現有系統(tǒng)的基本的處理流程和數據流程。此流程可用圖表即流程圖的形 式表示，并加以敘述。 A32 工作負荷 列出現有系統(tǒng)所承擔的工作及工作量。 A33 費用開支 列出由于運行現有系統(tǒng)所引起的費用開支，如人力

45、、設備、空間、支持性服 務、材料等項開支以及開 支總額。 A34 人員 列出為了現有系統(tǒng)的運行和維護所需要的人員的專業(yè)技術類別和數量。 A35 設備 列出現有系統(tǒng)所使用的各種設備。 A36 局限性 列出本系統(tǒng)的主要的局限性，例如處理時間趕不上需要，響應不及時，數據 存儲能力不足，處理功能 不夠等。并且要說明，為什么對現有系統(tǒng)的改進性維 護已經不能解決問題。 A 4 所建議的系統(tǒng) 本章將用來說明所建議系統(tǒng)的目標和要求將如何被滿足。 A41 對所建議系統(tǒng)的說明 概括地說明所建議系統(tǒng)， 并說明在第 A2 章中列出的那些要求將如何得到滿 足，說明所使用的基本 方法及理論根據。 A4 2 處理流程和數據

46、流程 給出所建議系統(tǒng)的處理流程和數據流程。 A4 3 改進之處 按 A 2 2 條中列出的目標，逐項說明所建議系統(tǒng)相對于現存系統(tǒng)具有的改 進。 A44 影響 說明在建立所建議系統(tǒng)時，預期將帶來的影響，包括： A 4 4 1 對設備的影響 說明新提出的設備要求及對現存系統(tǒng)中尚可使用的設備須作出的修改。 A 4 4 2 對軟件的影響 說明為了使現存的應用軟件和支持軟件能夠同所建議系統(tǒng)相適應。而需要對 這些軟件所進行的修 改和補充。 A 4 4 3 對用戶單位機構的影響 說明為了建立和運行所建議系統(tǒng)，對用戶單位機構、人員的數量和技術水平 等方面的全部要求。 A 4 4 4 對系統(tǒng)運行過程的影響 說明

47、所建議系統(tǒng)對運行過程的影響，如： a 用戶的操作規(guī)程； b .運行中心的操作規(guī)程； C .運行中心與用戶之間的關系； d .源數據的處理； e .數據進入系統(tǒng)的過程； f.對數據保存的要求，對數據存儲、恢復的處理； g .輸出報告的處理過程、存儲媒體和調度方法； h .系統(tǒng)失效的后果及恢復的處理辦法。 A. 4. 4. 5 對開發(fā)的影響 說明對開發(fā)的影響，如： a .為了支持所建議系統(tǒng)的開發(fā)，用戶需進行的工作； b .為了建立一個數據庫所要求的數據資源； C.為了開發(fā)和測驗所建議系統(tǒng)而需要的計算機資源； d .所涉及的保密與安全問題。 A. 4. 4. 6 對地點和設施的影響 說明對建筑物改造

48、的要求及對環(huán)境設施的要求。 A. 4. 4. 7 對經費開支的影響 扼要說明為了所建議系統(tǒng)的開發(fā)，設計和維持運行而需要的各項經費開支。 A . 4. 5 局限性 說明所建議系統(tǒng)尚存在的局限性以.及這些問題未能消除的原因。 A. 4. 6 技術條件方面的可行性 本節(jié)應說明技術條件方面的可行性，如： a .在當前的限制條件下，該系統(tǒng)的功能目標能否達到； b .利用現有的技術，該系統(tǒng)的功能能否實現； C .對開發(fā)人員的數量和質量的要求并說明這些要求能否滿足； d .在規(guī)定的期限內，本系統(tǒng)的開發(fā)能否完成。 A. 5 可選擇的其他系統(tǒng)方案 扼要說明曾考慮過的每一種可選擇的系統(tǒng)方案， 包括需開發(fā)的和可從國

49、內國外 直接購買的，如果沒 有供選擇的系統(tǒng)方案可考慮，則說明這一點 A51 可選擇的系統(tǒng)方案 1 參照第 A4 章的提綱， 說明可選擇的系統(tǒng)方案 1，并說明它未被選中的理由 A52 可選擇的系統(tǒng)方案 2 按類似 A 5 1 條的方式說明第 2 個乃至第。個可選擇的系統(tǒng)方案。 A 6 投資及效益分析 A61 支出 對于所選擇的方案， 說明所需的費用。 如果已有一個現存系統(tǒng)， 則包括該系統(tǒng) 繼續(xù)運行期間所需的費用。 A 6 1 1 基本建設投資 包括采購、開發(fā)和安裝下列各項所需的費用，如： a. 房屋和設施； b A DP 設備； C .數據通訊設備； d .環(huán)境保護設備； e. 安全與保密設備；

50、 f. ADP 操作系統(tǒng)的和應用的軟件； g. 數據庫管理軟件。 A . 6 . 1 . 2 其他一次性支出 包括下列各項所需的費用，如： a. 研究（需求的研究和設計的研究）； b. 開發(fā)計劃與測量基準的研究； C .數據庫的建立； d. ADP 軟件的轉換； e. 檢查費用和技術管理性費用； f. 培訓費、旅差費以及開發(fā)安裝人員所需要的一次性支出； g. 人員的退休及調動費用等。 A . 6 . 1 . 3 非一次性支出 列出在該系統(tǒng)生命期內按月或按季或按年支出的用于運行和維護的費用，包 括： a. 設備的租金和維護費用； b 軟件的租金和維護費用； C .數據通訊方面的租金和維護費用；

51、d 人員的工資、獎金； e房屋、空間的使用開支； f 公用設施方面的開支； g.保密安全方面的開支； h 其他經常性的支出等。 A62 收益 對于所選擇的方案， 說明能夠帶來的收益， 這里所說的收益， 表現為開支費用 的減少或避免、 差錯的減少、 靈活性的增加、 動作速度的提高和管理計劃方面的 改進等，包括； A . 6. 2. 1 一次性收益 說明能夠用人民幣數目表示的一次性收益， 可按數據處理、 用戶、管理和支持 等項分類敘述，如： a. 開支的縮減包括改進了的系統(tǒng)的運行所引起的開支縮減，如資源要求的減 少，運行效率的改進，數據進入、存貯和恢復技術的改進，系統(tǒng)性能的可監(jiān)控， 軟件的轉換和優(yōu)

52、化，數據壓縮技術的采用，處理的集中化分布化等； b價值的增升包括由于一個應用系統(tǒng)的使用價值的增升所引起的收益，如資 源利用的改進，管理和運行效率的改進以及出錯率的減少等； C 其他如從多余設備出售回收的收入等。 A . 6. 2. 2 非一次性收益 說明在整個系統(tǒng)生命期內由于運行所建議系統(tǒng)而導致的按月的、 按年的能用人 民幣數目表示的收益，包括開支的減少和避免。 A. 6. 2. 3 不可定量的收益 逐項列出無法直接用人民幣表示的收益， 如服務的改進， 由操作失誤引起的風 險的減少， 信息掌握情況的改進， 組織機構給外界形象的改善等。 有些不可捉摸 的收益只能大概估計或進行極值估計（按最好和最

53、差情況估計）。 A. 6. 3 收益投資比 求出整個系統(tǒng)生命期的收益投資比值。 A. 6. 4 投資回收周期 求出收益的累計數開始超過支出的累計數的時間。 A. 6. 5 敏感性分析 所謂敏感性分析是指一些關鍵性因素如系統(tǒng)生命期長度、系統(tǒng)的工作負荷量、 工作負荷的類型與這些不同類型之間的合理搭配、 處理速度要求、 設備和軟件的 配置等變化時， 對開支和收益的影響最靈敏的范圍的估計。 在敏感性分析的基礎 上做出的選擇當然會比單一選擇的結果要好一些。 A 7 社會因素方面的可行性 本章用來說明對社會因素方面的可行性分析的結果，包括： A71 法律方面的可行性 法律方面的可行性問題很多， 如合同責任

54、、侵犯專利權、 侵犯版權等方面的陷 井，軟件人員通常是不熟悉的，有可能陷入，務必要注意研究。 A7 2 使用方面的可行性 例如從用戶單位的行政管理、 工作制度等方面來看， 是否能夠使用該軟件系統(tǒng)； 從用戶單位的工作人員的素質來看， 是否能滿足使用該軟件系統(tǒng)的要求等等， 都 是要考慮的。 A 8 結論 在進行可行性研究報告的編制時，必須有一個研究的結論。結論可以是： a. 可以立即開始進行； b. 需要推遲到某些條件（例如資金、人力、設備等）落實之后才能開始進行; c. 需要對開發(fā)目標進行某些修改之后才能開始進行； d. 不能進行或不必進行（例如因技術不成熟、經濟上不合算等）。 附錄 項目開發(fā)計

55、劃的編寫提示 B. 1 引言 B. 1. 1編寫目的 說明編寫這份項目開發(fā)計劃的目的，并指出預期的讀者。 B . 1 . 2 背景 說明： a. 待開發(fā)的軟件系統(tǒng)的名稱； b. 本項目的任務提出者、開發(fā)者、用戶及實現該軟件的計算中心或計算機網 絡； C .該軟件系統(tǒng)同其他系統(tǒng)或其他機構的基本的相互來往關系。 B. 1. 3 定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。 B. 1. 4 參考資料 列出用得著的參考資料，如： a.本項目的經核準的計劃任務書或合同、上級機關的批文； b. 屬于本項目的其他已發(fā)表的文件； C 本文件中各處引用的文件、資料，包括所要用到的軟件開發(fā)標準

56、。列出 這些文件資料的標題、 文件編號、 發(fā)表日期和出版單位， 說明能夠得到這些文件 資料的來源。 B. 2 項目概述 B . 2. 1 工作內容 簡要地說明在本項目的開發(fā)中須進行的各項主要工作。 B. 2. 2 主要參加人員 扼要說明參加本項目開發(fā)工作的主要人員的情況，包括他們的技術水平。 B. 2. 3 產品 B. 2. 31 程序 列出需移交給用戶的程序的名稱、 所用的編程語言及存儲程序的媒體形式， 并 通過引用有關文件， 逐項說明其功能和能力。 B. 2. 3. 2 文件 列出需移交給用戶的每種文件的名稱及內容要點。 B. 2. 3. 3 服務 列出需向用戶提供的各項服務， 如培訓安裝

57、、 維護和運行支持等， 應逐項規(guī)定 開始日期、所提供支持 的級別和服務的期限。 B. 2. 3. 4 非移交的產品 說明開發(fā)集體應向本單位交出但不必向用戶移交的產品 （文件甚至某些程序） 。 B . 2. 4 驗收標準 對于上述這些應交出的產品和服務，逐項說明或引用資料說明驗收標準。 B. 2. 5完成項目的員遲用限 B. 2. 6 本計劃的批準者和批準日期 B. 3 實施計劃 B. 3. 1 工作任務的分門與人員分工 對于項目開發(fā)中需完成的各項工作， 從需求分析、 設計、實現、測試直到維護， 包括文件的編制、審批、打印、分發(fā)工作，用戶培訓工作，軟件安裝工作等，按 層次進行分解，指明每項任務的

58、負責人和參加人員。 B . 3. 2 接口人員 說明負責接口工作的人員及他們的職責，包括： a .負責本項目同用戶的接口人員； b負責本項目同本單位各管理機構，如合同計劃管理部門、財務部門、質量 管理部門等的接口人員； c. 負責本項目同各分合同負責單位的接口人員等。 B33 進度 對于需求分析、設計、編碼實現、測試、移交、培訓和安裝等工作，給出每 項工作任務的預。 定開始日期、 完成日期及所需資源， 規(guī)定各項工作任務完成的 先后順序以及表征每項工作任務完成的標志性事件（即所謂 “里程碑 ”）。 B. 3. 4 預算 逐項列出本開發(fā)項目所需要的勞務（包括人員的數量和時間）以及經費的預 算（包括

59、辦公費、差旅費、機時費、資料費、通訊設備和專用設備的租金等）和 來源。 B. 3. 5 關鍵問題 逐項列出能夠影響整個項目成敗的關鍵問題、技術難點和風險，指出這些問 題對項目的影響。 B. 4 支持條件 說明為支持本項目的開發(fā)所需要的各種條件和設施。 B . 4. 1 計算機系統(tǒng)支持 逐項列出開發(fā)中和運行時所需的計算機系統(tǒng)支持，包括計算機、外圍設備、 通訊設備、模擬器、編譯 （或 匯編）程序、操作系統(tǒng)、數據管理程序包、數據 存儲能力和測試支持能力等，逐項給出有關到貨日期、 使用時間的要求。 B. 4. 2 需由用戶承擔的工作 逐項列出需要用戶承擔的工作和完成期限。包括需由用戶提供的條件及提供

60、時間。 B. 4. 3 由外單位提供的條件 逐項列出需要外單位分合同承包者承擔的工作和完成的時間，包括需要由外 單位提供的條件和提 供的時間。 B. 5 專題計劃要點 說明本項目開發(fā)中需制訂的各個專題計劃 （如分合同計劃、 開發(fā)人員培訓計劃、 測試計劃、安全保密 計劃、質量保證計劃、配置管理計劃、用戶培訓計劃、系 統(tǒng)安裝計劃等）的要點。 附錄 C 軟件需求說明書的編寫提示 C1 引言 C 1 1 編寫目的 說明編寫這份軟件需求說明書的目的，指出預期的讀者。 C12 背景 說明： a 待開發(fā)的軟件系統(tǒng)的名稱； b 本項目的任務提出者、開發(fā)者、用戶及實現該軟件的計算中心或計算機網 絡； C 該軟件