【正文】 ？并簡述其特點 ？每類文檔的特點與內容？ ，包括那些類型。 (4) 經(jīng)驗與教訓： 項目開發(fā)過程中的經(jīng)驗與教訓；對今后工作的建議；寫出對外發(fā)表的論文 。 (2) 項目的完成情況： 包括項目構成與主要功能；項目性能與技術指標；計劃與實際進度對比；費用預算與實際費用的對比等 。 項目評價報告主要包括以下內容 : (1) 概述 (2) 系統(tǒng)構成 (3) 系統(tǒng)達到設計目標的情況 (4) 系統(tǒng)的可靠性 、 安全性 、 保密性 、 可維護性等狀況 (5) 系統(tǒng)的經(jīng)濟效益與社會效益的評價 (6) 總結性評價 項目開發(fā)總結報告 ? 項目開發(fā)總結報告中在項目正式運行一段時間后 ，開發(fā)人員所做的工作總結 ， 目的是總結經(jīng)驗 ， 找出不足 ， 為今后的開發(fā)工作提供借鑒 。 (3) 問題解釋： 解釋了系統(tǒng)使用中可能出現(xiàn)的問題及解決辦法 ， 如非常規(guī)操作命令 、 系統(tǒng)恢復過程及意外情況 、與開發(fā)單位的聯(lián)系方式等 。 (2) 使用說明： 系統(tǒng)操作使用說明較為詳細地說明了操作的目的 、 過程 、 方式 、 輸入輸出的數(shù)據(jù)等 。 (6) 結論 ： 項目功能評價 、 性能技術指標評價 、 結論 。 (4) 測試方案： 測試的方法 、 測試數(shù)據(jù) 、 測試步驟 、 測試中故障的解決方案等 。 (2) 測試環(huán)境： 有關軟 、 硬件 、 通信 、 數(shù)據(jù)庫 、 人員等情況 。 (4)協(xié)調方法： 項目開發(fā)中各個單位 、 階段之間的銜接 、 協(xié)調方法 、負責人 、 權限等 。 可以用工作進度表 、 甘特圖 、 網(wǎng)絡圖及關鍵路徑法等工具輔助管理 。 項目開發(fā)計劃報告 項目開發(fā)計劃報告主要包括以下內容 : (1)概述： 主要包括系統(tǒng)開發(fā)的主要目標 、 基本方針 、 參加人員 、 工作階段和內容等 。 ? 其他可選方案及國內外同類方案的比較 。 ? 新系統(tǒng)對現(xiàn)行系統(tǒng)的影響 。 ? 可行性研究的基本準則 。 (1)可行性研究報告主要包括以下內容 : ? 系統(tǒng)概述 。 可行性研究報告 可行性研究階段的文檔是可行性研究報告 。 (7) 開始可行性研究的組織隊伍 、 機構與預算 。 (5) 驗收標準和方法 。 (3) 經(jīng)費預測和經(jīng)費來源 。 ? 項目開發(fā)立項報告主要包括以下內容 : (1) 概述：概述現(xiàn)行系統(tǒng)的組織結構 、 功能 、 業(yè)務流程以及存在的主要問題 。 ? 文檔產(chǎn)品發(fā)布： 桌面發(fā)布包 、 技術工作包等 。 本章要點 一、軟件項目文檔概述 ? 項目文檔管理的概念 ? 項目文檔的分類 二、項目文檔的質量 ? 項目文檔結構 ? 文檔標準 三、項目文檔準備 四、主要項目文檔 項目文檔準備 文檔的準備分 3個階段 ： ? 文檔制作： 文字處理器 、 文本格式器 、 表格和公式編輯器 、 繪圖工具包等 。 ? 盡可能地逐條列舉事實。 ? 簡明定義用到的專業(yè)術語。 ? 段落簡短。 ? 運用正確的術語和語法結構。 ? 文檔標準要適用于所有項目文檔及用戶文檔的最初版本。 ? 文檔解釋標準： 文檔解釋標準定義了文檔的總體“建筑風格”，包括文檔中字體的大小、顏色及風格的定義等。對于正式的文檔，它的識別標準可以是由配置管理人員專門定義的；對于非正式的文檔，其識別標準可以由項目經(jīng)理來定義。 ? 交互標準： 通過電子郵件和文檔數(shù)據(jù)庫交換文檔變得越來越重要 ， 交互標準使得所有的文檔都存在可比性 。 ? 過程標準： 這種標準定義了高質量文檔應該遵守的過程 。 ?文檔的結構通常應當是嚴整的，并且有一定的標準 。 ?如果文檔包括許多細節(jié)性參考信息，應該有附錄。 ? 維護指導文檔 ， 主要描述系統(tǒng)已知的問題 、 軟件支持 、硬件支持等信息 ， 以便維護時使用 。 這些列表包括程序注釋 、 用來解釋代碼中復雜代碼段和采用的編碼方法等 。 ? 每個子系統(tǒng)的規(guī)范和設計說明書 。 ? 系統(tǒng)體系結構文檔 。 ? 備忘錄及電子信息 ：主要記錄了每天項目經(jīng)理和開發(fā)人員之間的詳細交流信息 。 ? 標準報告： 這些文檔規(guī)定了軟件過程應該如何實現(xiàn) ， 這些可以是國際標準 、 國家標準 、 行業(yè)標準等 。 過程文檔 ? 軟件項目計劃 、 預測和進度安排文檔： 這些文檔由項目經(jīng)理負責產(chǎn)生 ， 以便預測和控制軟件的開發(fā)過程 。 ? 產(chǎn)品文檔 ， 是那些描述正在開發(fā)的產(chǎn)品的資料。 ? 能作為最終用戶或管理員的用戶手冊，使用戶知道如何使用、維護及管理系統(tǒng)。 ? 能為軟件項目的維護工程師提供有關信息系統(tǒng)的資料和知識庫。 ? 有三種方式都可以結束合同： ①成功完成； ②相互協(xié)商同意結束 ,但沒有成本結算； ③實質性違約。 合同收尾 ? 合同收尾指買方通過其授權的合同管理員向賣方發(fā)出合同已經(jīng)完成的正式書面通知。 ? 在合同收尾后，未解決的爭議可能需進入訴訟程序。在多階段項目中，合同條款可能僅適用于項目的某個特定階段。包括諸如對開發(fā)記錄進行更新以反映最終結果，將更新后的記錄進行歸檔供將來項目使用的管理活動。根據(jù)合同中的需求一項項的核對，是否完成了合同所有的要求。驗收人員審查承包商應交付的成果，如代碼、文檔等，確保這些成果是完整并正確的。驗收時承包商準備好待驗收的工作成果，并將必要材料提前交給外包管理小組。 外包交付 ? 當軟件項目完成后，軟件外包管理小組啟動外包交付工作。雖然理論上可以把分包商納入自己的進度控制和質量控制體系，把其作為自己的一個項目部門來對待，但是客觀上由于分包商與業(yè)主距離較遠，人員不熟悉，各自有自己的企業(yè)文化和管理體制，雙方之間的信息溝通不暢，業(yè)主難以實時監(jiān)督分包商的開發(fā)進程和質量。這就需要業(yè)主對整個外包的過程進行監(jiān)控。 ? 對業(yè)主