【導讀】問題與對策、心得體會等等，產(chǎn)生《編程文檔》。甲方于本合同簽署之日起，在15日內，將合同總成交價的。以傳真向甲方確認。如甲方不按上述規(guī)定準時支付預付款，則交貨期作相應。乙方按合同規(guī)定在發(fā)貨時，將有關運輸提單或自提單、商業(yè)發(fā)。票、裝箱單和質量證書，以可靠方式寄遞給甲方。甲方收到以上單據(jù)的次日。成交價的40%，即人民幣（元），作為驗收款支付給乙方。甲方和乙方應以書面方式相互通知各方的開戶銀行、帳戶名稱、帳號。應負逾期付款的責任。甲方應及時作好準備，辦妥一切接貨手續(xù),在貨物到達后。四十八小時內提運完畢。對于因乙方誤發(fā)、多發(fā)或少發(fā)的物品，甲方應負責妥善保管，并及時通。本合同所有物品運抵甲方現(xiàn)場后，雙方代表共同參加開箱檢驗。外包裝完好無損，但箱內設備發(fā)現(xiàn)短缺或損傷，應由乙方負責補足或修理，其相關費用由乙方負擔。

　　

【正文】 技術開發(fā)隊伍中有臨時工嗎？ 本項目開發(fā)過程中是否會有核心人員辭職、調動？ 是否能保證“人員流動基本不會影響 工作的連續(xù)性”？ 項目經(jīng)理是否忙于行政事務而無暇顧及項目的開發(fā)工作？ 本項目是否得到上級領導的重視？ 上級領導是否隨時會抽調本項目的資源用于其它“高優(yōu)先級”的項目？ 上級領導 行政部門 合作部門 上級領導是否過多地介入本項目的事務并且瞎指揮？ 行政部門的辦事效率是否比較底，以至于拖項目的后腿？ 行政部門是否經(jīng)常干一些無益于生產(chǎn)力的事情，以至于騷擾本項目？ 機構是否能全面、公正地考核員工的工作業(yè)績？ 機構是否有較好的獎勵和懲罰措施？ 本項目的合作部門的態(tài)度積極嗎？是否應付了事 ？或者做事與承諾的不一致？ 技術風險 風險類型 檢查項 需求開發(fā) 需求管理 需求開發(fā)人員懂得如何獲取用戶需求嗎？效率高嗎？ 需求開發(fā)人員懂得項目所涉及的具體業(yè)務嗎？能否理解用戶的需求？ 需求文檔能夠正確地、完備地表達用戶需求嗎？ 需求開發(fā)人員能否與客戶對有爭議的需求達成共識？ 需求開發(fā)人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？ 綜合技術 開發(fā)能力 包括設計 編程、測試等 開發(fā)人員是否有開發(fā)相似產(chǎn)品的經(jīng)驗？ 待開發(fā)的產(chǎn)品是否要與未曾證實的軟硬件相連接？ 對開發(fā)人員而言，本項目的技術難度高嗎？ 開發(fā)人員是否已經(jīng)掌握了本項目的關鍵技術？ 如果某項技術尚未實踐過，開發(fā)人員能否在預定時間內掌握？ 開發(fā)小組是否采用比較有效的分析、設計、編程、測試工具？ 分析與設計工作是否過于簡單、草率，從而讓程序員邊做邊改？ 開發(fā)小組采用統(tǒng)一的編程規(guī)范嗎？ 開發(fā)人員對測試工作重視嗎？能保證測試的客觀性嗎？ 項目有獨立的測試人員嗎？懂得如何進行高效率地測試嗎？ 是否對所有重要的工作成果進行了同行評審（正式評審或快速檢查）？ 開發(fā)人員懂得版本控制、變 更控制嗎？能夠按照配置管理規(guī)范執(zhí)行嗎？ 開發(fā)人員重視質量嗎？是否會在進度延誤時降低質量要求？ 概要設計說明書 1 引言 1． 1 編寫目的 說明編寫這份概要設計說明書的目的，指出預期的讀者。 1． 2 背景 說明： a．待開發(fā)軟件系統(tǒng)的名稱； b．列出此項目的任務提出者、開發(fā)者、用戶以及將運行該軟件的計算站（中心）。 1． 3 定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。 1． 4 參考資料 列出有關的參考文件，如： a．本項目的 經(jīng)核準的計劃任務書或合同，上級機關的批文； b．屬于本項目的其他已發(fā)表文件； c．本文件中各處引用的文件、資料，包括所要用到的軟件開發(fā)標準。 列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠得到這些文件資料的來源。 2 總體設計 2． 1 需求規(guī)定 說明對本系統(tǒng)的主要的輸入輸出項目、處理的功能性能要求，詳細的說明可參見附錄 C。 2． 2 運行環(huán)境 簡要地說明對本系統(tǒng)的運行環(huán)境（包括硬件環(huán)境和支持環(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ī)模、復雜性和成敗風險增大時，文件編