【正文】 細說明本程序所選用的算法，具體的計算公式和計算步驟。以下給出的提綱是針對一般情況的。 風險級別：確定風險的嚴重性、可能性、風險系數(shù) 風險描述：緩解方案或者應急計劃。 3 項目過程定義 提示：簡要描述、繪制本項目的軟件生命周期模型。 說明：主要是在線用戶手冊與幫助系統(tǒng)，也包括其他的文檔 第三方產(chǎn)品 【可選】 說明：使用到的第三方產(chǎn)品相關的 使用許可、使用限制、接口標準。 動態(tài)數(shù)值需求說明：欲處理的事務和任務的數(shù)量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數(shù)據(jù)總量。包括輸入、輸出系統(tǒng)等系統(tǒng) 填寫與接口交互的系統(tǒng)名稱 系統(tǒng)類型 填寫是接口的數(shù)據(jù)源系統(tǒng)(source)還是目標系統(tǒng)(object) 數(shù)據(jù)庫 填寫交互系統(tǒng)使用的數(shù)據(jù)庫及版本 軟件 填寫交互系統(tǒng)的軟件名稱 架構類型 交互系統(tǒng)的架構類型是B/S 還是C/S。對軟件的數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告的描述。例如： 報表格式；數(shù)據(jù)命名；財務處理；審計追蹤，等等。分級和累積投票方法表明，必須解決的問題與干系人或用戶希望解決的問題大有不同。以下是幾項建議： 該任務由多少人來完成？是否總在變化？ 一個任務周期需要多長時間？執(zhí)行每項活動要用多長時間？是否總在變化？ 是否有特殊的環(huán)境約束：移動、戶外、乘機旅行等？ 目前使用的是哪些系統(tǒng)平臺？以后會使用哪些平臺？ 還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？ 在此處可以從業(yè)務模型中摘錄一些內容來概述所涉及的任務和角色等等。 參考文檔 說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括計劃任務書、合同、批文、引用到的文件、資料及軟件開發(fā)標準等。 說明：業(yè)務對象：業(yè)務流程中涉及的單據(jù)、報表等。 管理綜述 【可選】 說明：主要描述該業(yè)務的管理特點和管理模式。 2. 項目計劃 . 項目團隊 提示：說明項目團隊的角色、知識技能要求、建議人選、人數(shù)、工作時間，如下表所示。 第六十七條 以上各要求需要在開發(fā)合同中明確。 第六十一條 項目組提交全部經(jīng)審批的交付物給PMO存檔。 第五十五條 項目經(jīng)理同合作開發(fā)商明確規(guī)定項目變更的范圍和處理方式，重點關注需求和設計變更。 第四十八條 《系統(tǒng)上線計劃》內容應包括但不限于： （一） 部署方式和資源分配（包括人力資源及服務器資源）； （二） 上線工作時間表； （三） 上線操作步驟以及問題處理步驟； （四） 項目階段性里程碑和成果匯報（項目執(zhí)行狀態(tài)的審閱、進度安排等）； （五） 數(shù)據(jù)遷移的需求和實施計劃； （六） 完整可行的應急預案和“回退”計劃； （七） 用戶培訓計劃（包括：培訓計劃、培訓手冊、培訓考核等）； （八） 公司下發(fā)的系統(tǒng)標準參數(shù)配置。 第九節(jié) 系統(tǒng)驗收 第四十二條 系統(tǒng)主要使用部門及技術研發(fā)部聯(lián)合組成獨立系統(tǒng)驗收小組，也可授權原項目組作為驗收小組。各相關部門驗收轉換結果后在該報告上簽字確認。用戶培訓的完成度應為實施后評估的指標之一。技術研發(fā)部測試組出具《系統(tǒng)測試報告》（附件十一），測試人員簽字確認測試結果。項目組對已授權訪問生產(chǎn)環(huán)境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經(jīng)授權的人員才能訪問到生產(chǎn)環(huán)境。業(yè)務組組長和開發(fā)組組長應參加此評審并對評審意見簽字確認。 第十五條 在項目的各個階段，業(yè)務組組長和開發(fā)組組長需配合項目經(jīng)理制定階段性項目計劃。 第十條 業(yè)務組在獲得《業(yè)務需求說明書》后，提出技術需求和解決方案，并對系統(tǒng)進行定義，出具《系統(tǒng)需求規(guī)格說明書》（附件三）。 第二節(jié) 立項管理 第六條 提出項目需求的部門參與公司層面立項，進行立項的技術可行性分析，編寫《立項分析報告》（附件一），開展前期籌備工作。技術開發(fā)管理制度2014（試行）主 題： 軟件開發(fā)管理制度 文檔編號： 版本說明：版本號版本日期作者備注 2014年10月30日牟寶林創(chuàng)建 2014年10月30日牟寶林審批 目錄第一節(jié) 總 則 3第二節(jié) 立項管理 3第三節(jié) 需求分析 4第四節(jié) 項目計劃和監(jiān)控 4第五節(jié) 系統(tǒng)設計 5第六節(jié) 系統(tǒng)實現(xiàn) 5第七節(jié) 系統(tǒng)測試和用戶測試 6第八節(jié) 試運行 7第九節(jié) 系統(tǒng)驗收 8第十節(jié) 系統(tǒng)上線 8第十一節(jié) 合作開發(fā)管理 9第十二節(jié) 系統(tǒng)交付 10第十三節(jié) 外包開發(fā)管理 10第十四節(jié) 附則 10附件一 立項分析報告 11附件二 業(yè)務需求說明書 14附件三 系統(tǒng)需求規(guī)格說明書 17附件四 需求變更申請 26附件五 項目計劃書 28附件六 項目計劃變更說明 32附件七 設計說明書 33附件八 單元測試用例 36附件九 設計評審報告 38附件十 系統(tǒng)/用戶測試計劃 40附件十一 系統(tǒng)/用戶測試報告 43附件十二 試運行計劃 44附件十三 數(shù)據(jù)遷移計劃 46附件十四 數(shù)據(jù)遷移報告 48附件十五 試運行報告 50附件十六 系統(tǒng)驗收報告 51附件十七 系統(tǒng)上線計劃 54附件十八 系統(tǒng)驗收評估報告 57附件十九 系統(tǒng)交付申請 59第一節(jié) 總 則 第一條 為規(guī)范自有軟件研發(fā)以及外包軟件的管理工作，特制定本制度。 第五條 除特別指定，本制度中項目組包括業(yè)務組（或需求提出組）、開發(fā)組（可能包括網(wǎng)絡管理員和合作開發(fā)商）。經(jīng)系統(tǒng)使用部門審批確認，作為業(yè)務需求基線。 第十四條 需求分析過程中，項目經(jīng)理組織制定詳細的《項目計劃書》（附件五），包括具體任務描述和項目進度表等。公司主管領導組織相關人員對概要設計進行評審，出具《設計評審報告》（附件九）。對開發(fā)環(huán)境、測試環(huán)境與生產(chǎn)環(huán)境在物理或邏輯方面應該做到隔離；如果環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應定期檢查網(wǎng)絡設置。在系統(tǒng)測試中對新系統(tǒng)內部各模塊之間的接口和與其他系統(tǒng)的接口進行充分測試。 第三十五條 項目組聯(lián)合試運行單位進行相關系統(tǒng)部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。 第三十八條 數(shù)據(jù)遷移后，項目組對數(shù)據(jù)遷移的完整性和準確性作出檢查，出具《數(shù)據(jù)遷移報告》（附件十四），其中包括數(shù)據(jù)來源、轉換前狀態(tài)、轉換后狀態(tài)，數(shù)據(jù)遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。公司主管領導審閱試運行結果，決定試運行結束或延期。在上線計劃得到批準后才能開始部署上線工作。 第五十四條 合作開發(fā)商必須遵循公司《軟件開發(fā)管理制度》。 第十二節(jié) 系統(tǒng)交付 第六十條 在系統(tǒng)驗收通過后，項目組對運維組進行系統(tǒng)維護培訓。 第六十六條 項目組同外包開發(fā)商商定驗收的標準和方法。 . 項目范圍 提示：根據(jù)對現(xiàn)有需求的了解來確定項目基本范圍，說明本系統(tǒng)“應當包含的內容”和“不包含的內容”。 2 組織結構及業(yè)務 業(yè)務相關組織結構、人員組織結構 說明：如果客戶崗位設置復雜可分別設置，業(yè)務組織結構和人員組織結構 組織機構描述 角色職責 說明：將業(yè)務涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。 說明：描述具體的業(yè)務流程。 【可選】 說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。 干系人與用戶說明 【可選】 【可選】 詳細說明目標用戶的工作環(huán)境。對于列出的每個問題，需澄清以下要點： ? 為什么會出現(xiàn)這一問題？ ? 目前如何解決該問題？ ? 干系人需要什么樣的解決方案？ 務必要了解干系人或用戶對解決各個問題的相對重視程度。 格式限制說明：本項將指定由現(xiàn)有的標準或規(guī)則派生的要求。 b 報表或菜單的頁面打印格式和內容 c 輸入輸出的需求 說明：解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等。 【接口定義】 下表是對一些接口的具體描述:接口名稱 接口描述 填寫接口完成的任務 接口類型 填寫是輸入接口（inbound）還是輸出接口（outbound） 源系統(tǒng) 填寫接口輸入方系統(tǒng)或部件 目標系統(tǒng) 填寫接口輸出方系統(tǒng)或部件 廠商提供/客戶化開發(fā) 文件類型 填寫文件類型；若通過數(shù)據(jù)庫表來交互，請指明數(shù)據(jù)庫及表名 文件數(shù)量 峰值數(shù)據(jù)量 頻度 填寫數(shù)據(jù)處理的頻度 復雜度 批處理 /人工 填寫接口數(shù)據(jù)的驅動模式是人工（manual）還是自動(automatic)，還是都支持 接口類型 填寫是實時接口還是批量接口等 【其他系統(tǒng)詳細信息】 說明：列出所有與接口交互的外圍系統(tǒng)的詳細信息。名稱詳細要求靜態(tài)數(shù)值需求動態(tài)數(shù)值需求精度 時間特性要求可用性 可靠性 可維護性 安全性 可移植性 可擴展性 兼容性 … 靜態(tài)數(shù)值需求 說明：支持的終端數(shù)；支持并行操作的用戶數(shù)。指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。 （3）說明一些假設和依賴。 約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。 3程序1（標識符）設計說明 從本章開始，逐個地給出各個層次中的每個程序的設計考慮。 給出對每一個輸出項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式，數(shù)據(jù)值的有效范圍，輸出的形式、數(shù)量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。 說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。待評審的工作成果 工作成果名稱，標識符，版本，作者，時間… 技術評審方式 （正式評審）或者(走查) 評審時間 評審地點 參加技術評審的人員 類別名字工作單位職稱、職務：主持人 評審 小組 成員 記錄2. 缺陷識別和跟蹤 評審問題跟蹤表 編號 問題描述 問題類型 嚴重性 提交者 提交日期 問題處理負責人 解決措施/原因說明 問題解決狀態(tài) 實際關閉日期 問題關閉驗證人 備注 1 2 3 3. 評審結論與意見 提示：由主持人或評審員填寫此表格。 對于嚴格系統(tǒng)，應當補充“基于BUG密度”的規(guī)則： 相鄰n個CPU小時內“測試期BUG密度”全部低于某個值m。 2. 工作條件 提示：說明試運行地點、參加人員、軟硬件設施、經(jīng)費等要求。 4). 組織機制 提示：建立應急處理小組成員，明確職責到人。 2. 試運行目標 提示：說明本次試運行的主要內容與目標（必須是可驗證的）。 （2）雙方的責任人簽字認可。 4). 組織機制提示：建立應急處理小組成員，明確