【導讀】問題與對策、心得體會等等，產(chǎn)生《編程文檔》。甲方于本合同簽署之日起，在15日內，將合同總成交價的。乙方在收到上述款項后，以傳真向甲方確認。如甲方不按上述規(guī)定準時支付預付款，則交貨期作相應。應負逾期付款的責任。甲方應及時作好準備，辦妥一切接貨手續(xù),在貨物到達后。知乙方查處，由此發(fā)生的費用由乙方負擔。本合同所有物品運抵甲方現(xiàn)場后，雙方代表共同參加開箱檢驗。外包裝完好無損，但箱內設備發(fā)現(xiàn)短缺或損傷，應由乙方負責補足或修理，作，并對甲方人員進行技術指導，保證使“采購物品”達到預定的性能指標。測試情況記錄在《采購物品驗收報告》中。陷，雙方應當視問題的嚴重性給出合適的處理措施。乙方應當給出糾正缺陷，雙方協(xié)商第二次驗。品正式交付給甲方。保修期結束后乙方依然負責對所售設備進行維護或維。次日起，每日向乙方償付逾期付款部分總值的萬分之三的違約金。此項違約金額以逾期移。交設備部分貨款的總值的百分之五為限度。

　　

【正文】 和支持環(huán)境）的規(guī)定，詳細說明參見附錄 C。 2． 3 基本設計概念和處理流程 說明本系統(tǒng)的基本設計概念和處理流程，盡量使用圖表的形式。 2． 4 結構 用 一覽表及框圖的形式說明本系統(tǒng)的系統(tǒng)元素（各層模塊、子程序、公用程序等）的劃分，扼要說明每個系統(tǒng)元素的標識符和功能，分層次地給出各元素之間的控制與被控制關系． 2． 5 功能器求與程序的關系 本條用一張如下的矩陣圖說明各項功能需求的實現(xiàn)同各塊程序的分配關系： 2． 6 人工處理過程 說明在本軟件系統(tǒng)的工作過程中不得不包含的人工處理過程（如 果有的話）。 2． 7 尚未問決的問題 說明在概要設計過程中尚未解決而設計者認為在系統(tǒng)完成之前必須解決的各個問題。 3 接口設計 3． 1 用戶接口 說明將向用戶提供的命令和它們的語法結構，以及軟件的回答信息。 3． 2 外部接口 說明本系統(tǒng)同外界的所有接口的安排包括軟件與硬件之間的接口、本系統(tǒng)與各支持軟件之間的接 口關系。 3． 3 內部接口 說明本系統(tǒng)之內的各個系統(tǒng)元素之間的接口的安排。 4 運行設計 4． 1 運行模塊組合 說明對系統(tǒng)施加不同的外界運行控制時所引起的各種不同的運行模塊組合，說明 每 種運行所歷經(jīng)的內部模塊和支持軟件。 4． 2 運行控制 說明每一種外界的運行控制的方式方法和操作步驟。 4． 3 運行時間 說明每種運行模塊組合將占用各種資源的時間。 5 系統(tǒng)數(shù)據(jù)結構設計 5． 1 邏輯結構設計要點 給出本系統(tǒng)內所使用的每個數(shù)據(jù)結構的名稱、標識符以及它們之中每個數(shù)據(jù)項、記錄、文卷和系的標識、定義、長度及它們之間的層次的或表格的相互關系。 5． 2 物理結構設計要點 給出本系統(tǒng)內所使用的每個數(shù)據(jù)結構中的每個數(shù)據(jù)項的存儲要求，訪問方法、存取單位、存取的物理關系（索引、設備、存儲區(qū)域） 、設計考慮和保密條件。 5． 3 數(shù)據(jù)結構與程序的關系 說明各個數(shù)據(jù)結構與訪問這些數(shù)據(jù)結構的形式 : 6 系統(tǒng)出錯處理設計 6． 1 出錯信息 用一覽表的方式說朗每種可能的出錯或故障情況出現(xiàn)時，系統(tǒng)輸出信息的形式、含意及處理方法。 6． 2 補救措施 說明故障出現(xiàn)后可能采取的變通措施，包括： a．后備技術說明準備采用的后備技術 ，當原始系統(tǒng)數(shù)據(jù)萬一丟失時啟用的副本的建立和啟動的技術，例如周期性地把磁盤信息記錄到磁帶上去就是對于磁盤媒體的一種后備技術； b．降效技術說明準備采用的后備技術，使用另一個效率稍低的系統(tǒng)或方法來求得所需結果的某些部分，例如一個自動系統(tǒng)的降效技術可以是手工操作和數(shù)據(jù)的人工記錄； c．恢復及再啟動技術說明將使用的恢復再啟動技術，使軟件從故障點恢復執(zhí)行或使軟件從頭開始重新運行的方法。 6． 3 系統(tǒng)維護設計 說明為了系統(tǒng)維護的方便而在程序內部設計中作出的安排，包括在程序中專門安排用于系統(tǒng)的檢查與維護的 檢測點和專用模塊。 供應商評估報告 { 采購物品名稱 } 供應商評估報告 文件狀態(tài)： [√] 草稿 [ ] 正式發(fā)布 [ ] 正在修改 文件標識： CompanyProjectOPMPMEVALUATE 當前版本： 作者： 完成日期： YearMonthDay 版 本 歷 史 版本 /狀態(tài) 作者 參與者 起止日期 備注 目 錄 1. 采購物品介紹 2. 候選供應商介紹 3. 對候選供應商 A 的評估 4. 對候選供應商 B 的評估 5. 綜合競爭力排名與風險分析 6. 結論 附錄 . 候選供應商的材料和應標書 1. 采購物品介紹 提示：參見采購競標邀請書。 2. 候選供應商介紹 候選供應商名稱 介紹 聯(lián)系方式 3. 對候選供應商 A 的評估 提示：采購管理小組可以根據(jù)實際情況適當修改檢查項。 檢查項 結論、描述 供應商的產(chǎn)品部件的功能是否符合本產(chǎn)品的需求？ 供應商的產(chǎn)品部件的質量是否令人滿意？ 供應商的產(chǎn)品部件的性能價格比是否令人滿 意？ 供應商的供貨周期是否可以接受？ 供應商能否提供較好的服務（維護）？ 供應商的信譽如何？外界對其評價如何？ 供應商是否已經(jīng)取得業(yè)界認可的證書如 ISO質量認證、 CMM 2 級以上認證？ ? 4. 對候選供應商 B 的評估 ? 5. 綜合競爭力排名與風險分析 排名 候選供應商名稱 風險分析 結論 第 1名 可選 /不可選 第 2名 可選 /不可選 第 3名 可選 /不可選 ? 6. 結論 提示：（ 1）采購管理小組挑選出最合適的候選供應商。（ 2）如果所有的候 選供應商都不合格，則不必挑選供應商。 評估結論 外包采購小組 簽字 附錄 . 候選供應商的材料和應標書 計算機軟件產(chǎn)品開發(fā)文件編制指南（ GB 856788）之二 黎宇 （轉載自國家計算機標準和文件模板） 第一篇 文件的編制指導 4 軟件生存周期與各種文件的編制 一項計算機軟件，從出現(xiàn)一個構思之日起，經(jīng)過這項軟件開發(fā)成功投入使用，直到最后決 定停止使 用，并被另一一項軟件代替之時止，被認為是該軟件的一個生存周期。一般地說這個軟件生存周期可以分成以下六個階段： 可行性與計劃研究階段 需求分析階段 設計階段 實現(xiàn)階段 測試階段 運行與維護階段 在可行性研究與計劃階段內，要確定該軟件的開發(fā)目標和總的要求，要進行可行性分析、投資一收益分析、制訂開發(fā)計劃，并完成應編制的文件。 在需求分析階段內，由系統(tǒng)分析人員對被設計的系統(tǒng)進行系統(tǒng)分析，確定對該軟件的各項功能、性能需求和設計約束，確定對文件編制的要求，作為本階段工作的 結果，一般地說，軟件需求說明書、數(shù)據(jù)要求說明書和初步的用戶手冊應該編寫出來。 在設計階段內，系統(tǒng)設計人員和程序設計人員應該在反復理解軟件需求的基礎上，提出多個設計，分析每個設計能履行的功能并進行相互比較，最后確定一個設計，包括該軟件的結構、模塊的劃分、功能的分配以及處理流程。在被設計系統(tǒng)比較復雜的情況下，設計階段應分解成概要設計階段和詳細設計階段兩個步驟。在一般情況下，應完成的文件包括：概要設計說明書、詳細設計說明書和測試計劃初稿。 在實現(xiàn)階段內，要完成源程序的編碼、編譯（或匯編）和排錯調試得到無語 法錯的程序清單，要開始編寫模塊開發(fā)卷宗，并且要完成用戶手冊、操作手冊等面向用戶的文件的編寫 工作，還要完成測試計劃的編制。 在測試階段，該程序將被全面地測試，已編制的文件將被檢查審閱。一般要完成模塊開發(fā)卷宗和測試分析報告，作為開發(fā)工作的結束，所生產(chǎn)的程序、文件以及開發(fā)工作本身將逐項被評價，最后寫出項目開發(fā)總結報告。 在整個開發(fā)過程中（即前五個階段中），開發(fā)集體要按月編寫開發(fā)進度月報。 在運行和維護階段，軟件將在運行使用中不斷地被維護，根據(jù)新提出的需求進行必要而且可能的擴充和刪改。 對于一項軟 件而言，其生存周期各階段與各種文件編寫工作的關系可見表互，其中有些文件的編寫工作可能要在若干個階段中延續(xù)進行。 表 1 軟 件 生 存 周 期 各 階 段 中 的 文 件 編 制 5 文件編制中的考慮因素 文件編制是一個不斷努力的工作過程。是一個從形成最初輪廓，經(jīng)反復檢查和修改，直到程序和文件正式交付使用的完整過程。其中每一步都要求工作人員做出很大努力。要保證 文 件編制的質量，要體現(xiàn)每個開發(fā)項目的特點，也要注意不要花太多的人力。為此，編制中要考慮如下各項因素。 5． 1 文件的讀者 每一種文件都具有特定的讀者。這些讀者包括個人或小組、軟件開發(fā)單位的成員或社會上的公眾、從事軟件工作的技術人員、管理人員或領導干部。他們期待著使用這些文件的內容來進行工作，例如設計、編寫程序、測試、使用、維護或進行計劃管理。因此，這些文件的作者必須了解自己的讀者，這些文件的編寫必須注意適應自己的特定讀者的水平、特點和要求。 5． 2 重復性 本指南第二篇中將列出的這十四種文件的內容 要求中，顯然存在某些重復。較明顯的重復有兩類。引言是每一種文件都要包含的內容，以向讀者提供總的梗概。第二類明顯的重復是各種文件中的說明部分，如對功能性能的說明、對輸入和輸出的描述、系統(tǒng)中包含的設備等。這是為了方便每種文件各自的讀者，每種產(chǎn)品文件應該自成體系，盡量避免讀一種文件時又不得不去參考另一種文件。當然，在每一種文件里，有關引言、說明等同其他文件相重復的部分，在行文上、在所用的術語上、在詳細的程度上，還是應該有一些差別，以適應各種文件的不同讀者的需要。 5． 3 靈活性 鑒于軟件開發(fā)是具有創(chuàng)造性的腦力 勞動，也鑒于不同軟件在規(guī)模上和復雜程度上差別極大，本指南認為在文件編制工作中應允許一定的靈活性。這種靈活性表現(xiàn)在如下各款。 5． 3． 1 應編制的文件種類 盡管本指南認為在一般情況下，一項軟件的開發(fā)過程中，應產(chǎn)生的文件有十四種，然而針對一項具體的軟件開發(fā)項目，有時不必編制這么多的文件，可以把幾種文件合并成一種。一般地說，當項目的規(guī)模、復雜性和成敗風險增大時，文件編制的范圍、管理手續(xù)和詳細程度將隨之增加。反之，則可適當減少。為了恰當?shù)卣莆者@種靈活性，本指南要求貫徹分工負責的原則，這意味著： a: 一 個軟件開發(fā)單位的領導機構應該根據(jù)本單位經(jīng)營承包的應用軟件的專業(yè)領域和本單位的管理能力，制定一個對文件編制要求的實施規(guī)定，主要是：在不同的條件下，應該形成哪些文件？這些文件的詳細程度？該開發(fā)單位的每一個項目負責人，必須認真執(zhí)行這個實施規(guī)定。這種規(guī)定的兩個例子可嘆 本指南的附錄 o（參考件）； b．對于一個具體的應用軟件項目，項目負責人應根據(jù)上述實施規(guī)定，確定一個文件編制計劃，主 中包括 : （ 1）應該編制哪幾種文件，詳細程度如何？ （ 2）各個文件的編制負責人和進度要求； （ 3）審查、批準的負責人和 時間進度安排； （ 4）在開發(fā)時期內，各文件的維護、修改和管理的負責人，以及批準手續(xù)。 每項工作必須落實到人。 這個文件編制計劃是整個開發(fā)計劃的重要組成部分； C．有關的設計人員則必須嚴格執(zhí)行這個文件編制計劃。 5． 3． 2 文件的詳細程度 從同一份提綱起草的文件的篇幅大小往往不同，可以少到幾頁，也可以長達幾百頁。對于這種差別本指南是允許的。此詳細程度取決于任務的規(guī)模、復雜性和項目負責人對該軟件的開發(fā)過程及運行環(huán)與所需要的詳細程度的判斷。 5． 3． 3 文件的擴展 當被開發(fā)系統(tǒng)的規(guī) 模非常大（例如源碼超過一百萬行）時，一種文件可以分成幾卷編寫，可以按其。 每一個系統(tǒng)分別編制，也可以按內容劃分成多卷，例如： 項目開發(fā)計劃可能包括：質量保證計劃，配置管理計劃， 用戶培訓計劃， 安裝實施計劃； 系統(tǒng)設計說明書可分寫成：系統(tǒng)設計說明書，子系統(tǒng)設計說明書； 程序設計說明書可分寫成：程序設計說明書，接口設計說明書，版本說明； 操作手冊可分寫成：操作手冊，安裝實施過程； 測試計劃可分寫成：測試計劃，測試設計說明， 測試規(guī)程，測試用例； 測試分析報告可分寫成：綜合測試報告，驗 收測試報告； 項目開發(fā)總結報告亦可分寫成項目開發(fā)總結報告和資源環(huán)境統(tǒng)計。 5． 3． 4 節(jié)的擴張與縮并 在有些文件中，可以使用本指南所提供的章、條標題，但在條內又存在一系列需要分別討論的因素 本指南認為，所有的條都可以擴展，可以進一步細分，以適應實際需要。反之，如果章條中的有些細節(jié)； 非必需，也可以根據(jù)實際情況縮并。此時章條的編號應相應地改變。 5． 3． 5 程序設計的表現(xiàn)形式 本指南對于程序的設計表現(xiàn)形式并未作出規(guī)定或限制，可以使用流程圖的形式、判定表的形式， 1 可以使用其他表現(xiàn)形式，如程序設 計語言（ PDL）、問題分析圖（ PAD）等。 5． 3． 6 文件的表現(xiàn)形式 本指南對于文件的表現(xiàn)形式亦未作出規(guī)定或限制，可以使用自然語言，也可以使用形式化語言。 5． 3． 7 文件的其他種類 當本指南中規(guī)定的文件種類尚不能滿足某些應用部門的特殊需要時，他們可以建立一些特殊的文件種類要求，例如軟件質量保證計劃、軟件配置管理計劃等，這些要求可以包含在本單位的文件編制實施規(guī)定中。 6 文件編制的管理工作 文件編制工作必須