.軟件開發管理制度第一節 總 則第一條 為規范自有軟件研發以及外包軟件的管理工作，特制定本制度。本制度適用于公司總公司軟件研發與管理，分公司參照執行。第二條 本制度中軟件開發指新系統開發和現有系統重大改造。第三條 本制度中自行開發是指主要依賴公司自身的管理、業務和技術力量進行系統設計、軟件開發、集成和相關的技術支持工作，一般僅向外購置有關的硬件設備和支撐軟件平臺；合作開發是公司與專業IT公司（合作商）共同協作完成IT應用的項目實施和技術支持工作，一般形式是公司負責提供業務框架，合作商提供技術框架，雙方組成開發團隊進行項目實施，IT系統的日常支持由研發部和合作商共同承擔，研發負責內部支持，合作商負責外部支持；外包開發是指將IT應用項目的設計、開發、集成、培訓等任務承包給某家專業公司（可以是專業的IT公司或咨詢公司等），由該公司（承包商）負責應用項目的實施。第四條 軟件開發遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監控、配置管理、合作開發管理和結項管理。軟件工程涉及需求管理、系統設計、系統實現、系統測試、用戶接受測試、試運行、系統驗收、系統上線和數據遷移。第五條 除特別指定，本制度中項目組包括業務組（營銷部、運維部）、IT組（研發部和合作開發商）。第二節 立項管理第六條 提出開發需求的營銷部、運維部等業務部門參與公司層面立項，研發部進行立項的技術可行性分析，共同編寫立項分析報告（附件一），開展前期籌備工作。立項分析報告應明確項目的范圍和邊界。第七條 應用系統主要使用部門將立項分析報告上交公司進行立項審批，以保證系統項目與公司整體策略相一致。第八條 立項分析報告得到批準后，成立項目組（如果是外包開發，則成立外包商項目組；如果是合作開發，則與外包商共同成立合作開發項目組，以下統稱“項目組”），項目組應包括業務組（由公司相關業務部門組成）和IT組（自行開發為研發部；外包開發為外包商成員；合作開發為研發部和外包商成員）。公司委派一名員工負責監督項目的進度，進行項目管理工作，確保開發能及時完成并能滿足業務需要。項目組人員的選擇應滿足項目對業務及技術要求，項目組人員應有足夠的業務和IT技術方面的專業知識來勝任項目各方面的工作。第三節 需求分析第九條 立項后業務組對用戶需求進行匯總整理，出具業務需求說明書（附件二），并確保業務需求說明書中包含了所有的業務需求。業務需求說明書經系統使用單位（用戶）確認，作為業務需求基線。第十條 IT組在獲得業務需求說明書后，提出技術需求和解決方案，并對系統進行定義，出具系統需求規格說明書（附件三）。系統需求規格說明書需詳細列出業務對系統的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關鍵指標等）。系統需求規格說明書需要由業務組提交給用戶相關業務流程負責人確認。第十一條 當業務需求發生變更時，業務組應提交需求變更申請（附件四），IT組組長審批后交給業務組與用戶確認方可實施。第十二條 項目組應對需求變更影響到的文檔及時更新。第四節 項目計劃和監控第十三條 軟件開發采用項目形式進行管理。項目經理（監理）負責整個項目的計劃、組織、領導和控制。第十四條 需求分析過程中，項目經理（監理）組織制定詳細的項目計劃書（附件五），包括具體任務描述和項目進度表等。第十五條 在項目的各個階段，業務組組長和IT組組長需配合項目經理（監理）制定階段性項目計劃。業務組組長和IT組組長需配合項目經理（監理）對項目計劃執行情況進行監控，確保項目按計劃完成。第十六條 項目計劃需要變更時，項目經理（監理）填寫項目計劃變更說明（附件六），并提交公司主管領導審批，通過審批后，交給業務組組長和IT組組長執行。第五節 系統設計第十七條 系統設計應分為概要設計和詳細設計，系統設計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。第十八條 在系統設計階段中，用戶應充分參與，確保系統設計能滿足系統需求。第十九條 項目組進行詳細設計，出具設計說明書（附件七）和單元測試用例（附件八）。設計說明書中需要定義系統輸入輸出說明和接口設計說明。公司主管領導組織相關人員對概要設計進行評審，出具設計評審報告（附件九）。業務組組長和IT組組長應參加此評審并對評審意見簽字確認。第二十條 設計評審均以業務需求說明書和系統需求規格說明書為依據，確保系統設計滿足全部需求。第二十一條 對已確認通過的系統設計進行修改需獲得管理部門、業務組組長和IT組組長的審批后方可進行。第二十二條 對系統設計的修改的文檔須由文檔管理人員進行歸檔管理。第六節 系統實現第二十三條 項目組根據設計說明書制定系統實現計劃，并提交項目經理（監理）對計劃可行性進行審批。第二十四條 系統實現包括程序編碼、單元測試和集成測試。第二十五條 項目組保證開發、測試和訪問環境獨立，為各環境建立訪問權限控制機制，并明確項目成員的職責分工。對開發環境、測試環境與訪問環境在物理或邏輯方面應該做到隔離；如果環境的分隔是通過邏輯形式實現的，應定期檢查網絡設置。項目組對已授權訪問環境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經授權的人員才能訪問。第二十六條 項目組進行單元測試和集成測試，測試人員簽字確認測試結果。第七節 系統測試和用戶測試第二十七條 項目組制定系統/用戶測試計劃（附件十），并提交項目經理（監理）對計劃可行性進行審批。第二十八條 系統/用戶測試計劃必須定義測試標準，并明確各種測試的測試步驟和需要的系統設置要求。第二十九條 項目組向數據擁有部門申請獲取測試用業務數據的使用權，對獲取的數據進行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。第三十條 項目組負責測試數據準備，測試用數據要足夠模擬使用環境中的實際數據。對已評定為敏感信息的數據進行敏感性處理和保護。第三十一條 IT組或合作開發商建立測試環境進行系統測試。在系統測試中對新系統內部各模塊之間的接口和與其他系統的接口進行充分測試。出具系統測試報告（附件十一），測試人員簽字確認測試結果。第三十二條 系統測試通過后，IT組配合業務組建立用戶測試環境，業務組根據用戶測試用例進行用戶測試，出具用戶測試報告（附件十一），業務組組長和IT組組長應在用戶測試報告中簽字確認。第三十三條 項目組完成系統幫助文檔（其中包括用戶操作手冊和安裝維護手冊）。凡涉及應用系統的變更，應對系統幫助文檔及時更新。第八節 試運行第三十四條 系統主要使用部門根據項目規模及影響決定試運行策略。第三十五條 項目組制定試運行計劃（附件十二），并制定試運行驗收指標，上報公司主管領導審批。試運行計劃中應包含問題應對機制，明確問題溝通渠道和職責分工。第三十六條 項目組聯合試運行單位進行相關系統部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。用戶培訓的完成度應為實施后評估的指標之一。第三十七條 項目組根據試運行計劃進行系統轉換和數據遷移。系統轉換前，檢查系統環境，確保運行環境能滿足新應用系統的需要。系統轉換時必須詳細記錄原系統中的重要參數、設置等系統信息，并填寫試運行報告相關內容。系統參數、設置的轉換工作作為系統上線的驗收的評估指標之一。第三十八條 數據遷移前，應制定詳細的數據遷移計劃（附件十三），數據遷移計劃中應包含遷移方案、測試方案、數據定義，新舊數據對照表、遷移時間、回退計劃等信息。數據遷移計劃需經項目經理（監理）和主管領導簽字審批。第三十九條 數據遷移后，項目組對數據遷移的完整性和準確性作出檢查，出具數據遷移報告（附件十四），其中包括數據來源、轉換前狀態、轉換后狀態，數據遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗收轉換結果后在該報告上簽字確認。第四十條 系統轉換和數據遷移由試運行單位業務部門和公司主管領導共同監督并進行驗收。第四十一條 系統轉換和數據遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位辦公室把系統運行情況（系統資源使用，反應速度等）記錄到試運行報告中。必要時，項目組應根據系統運行情況對應用系統進行優化。第四十二條 試運行達到試運行計劃規定的終止條件時，項目組編寫試運行報告（附件十五）。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。第九節 系統驗收第四十三條 系統主要用戶單位及公司項目組聯合組成獨立系統驗收小組，也可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統進行綜合評估。 第四十四條 驗收小組應根據驗收情況整理形成系統驗收報告（附件十六）提交系統主要使用部門和公司審閱。第四十五條 系統主要使用部門和研發部負責人根據系統測試、試運行情況簽署驗收意見。 第十節 系統上線第四十六條 系統上線應遵循穩妥、可控、安全的原則。第四十七條 通常情況下，系統上線包含數據遷移工作。第四十八條 項目組制定系統上線計劃（附件十七），上報公司主管領導審批。在上線計劃得到批準后才能開始部署上線工作。第四十九條 系統上線計劃內容應包括但不限于：1、部署方式和資源分配（包括人力資源及服務器資源）；2、上線工作時間表；3、上線操作步驟以及問題處理步驟；4、項目階段性里程碑和成果匯報（項目執行狀態的審閱、進度安排等）；5、數據遷移的需求和實施計劃；6、完整可行的應急預案和“回退”計劃；7、用戶培訓計劃（包括：培訓計劃、培訓手冊、培訓考核等）；8、總公司下發的系統標準參數配置。第五十條 上線單位在上線初期需加強日常運行狀態監控，出現問題時應及時處理，對重大問題應啟動緊急預案。第五十一條 在完成上線后要填寫系統驗收評估報告（附件十八），上報總公司項目組匯總整理。系統驗收評估報告內容包括：數據準確性、系統性能及穩定性、接口問題、權限問題、業務操作影響度、問題處理情況、備份、批處理等。第五十二條 上線單位管理層要對系統驗收評估報告進行審批簽字。第五十三條 公司主管領導批準結項后，業務組和IT組將整理的文檔提交各自部門統一管理。第十一節 合作開發管理第五十四條 合作開發商的選擇應遵循公司相關規定，合作商資質認定參見第三方管理制度。第五十五條 合作開發商必須遵循公司軟件開發管理制度。第五十六條 項目經理同合作開發商明確規定項目變更的范圍和處理方式，重點關注需求和設計變更。第五十七條 項目經理負責監控合作開發商的項目管理及軟件開發活動。合作開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，合作開發商需及時向項目經理匯報。第五十八條 IT組組長派專人監控合作開發商的質量保證過程。第五十九條 項目組同合作開發商商定驗收的標準和方法。第六十條 以上各要求需要在開發合同中明確。第十二節 外包開發管理第六十一條 立項申請得到公司主管領導的審批后，選定開發商，簽訂外包開發合同。第六十二條 項目經理負責監控外包開發商的項目管理及軟件開發活動。外包開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，外包開發商需及時向項目經理匯報。第六十三條 項目經理監控外包開發商的質量保證過程。第六十四條 項目組同外包開發商商定驗收的標準和方法。第六十五條 以上各要求需要在開發合同中明確。第十三節 角色與職責表第六十六條 主要角色及其職責如下表所示。企業在應用時，可以將各個角色映射到企業原有的崗位上，也可以依據角色建立新的崗位。一個人可以被賦予多個角色，視具體情況而定。常設角色職責簡述機構過程改進角色軟件工程過程組（SEPG）（1）制定適合于本機構的過程規范。（2）在機構范圍內推廣該規范（如培訓、考核），評估機構過程能力等。質量保證小組（QAG）（1）監督規范的實施，確保所有項目以及相關部門準照規范開展工作。（2）分析并解決機構內存在的共性質量問題，協組SEPG完善規范。項目管理過程角色機構領導（1）是機構內所有項目的主管，對立項管理和結項管理有最終決策權。（2）監督項目經理的工作，審批項目經理的各種申請。項目經理（1）向機構領導匯報工作。（2）是項目規劃、項目監控、風險管理和需求管理過程域的負責人。（3）監督項目成員的工作，審批項目成員的各種申請。項目研發過程角色需求分析員調查、分析并定義需求，撰寫相應的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。系統設計師根據需求文檔設計軟件系統的體系結構、用戶界面、數據庫、模塊等，并撰寫相應的設計文檔。程序員（1）根據系統設計文檔，編寫軟件系統的代碼。（2）隨時測試和檢查自己的代碼，及時消除代碼中的缺陷。測試員從事單元測試、集成測試和系統測試，主要工作包括制定測試計劃、設計測試用例、執行測試和撰寫測試報告。機構支撐過程角色配置管理員（1）為項目制定配置管理計劃。（2）創建并維護配置庫，如分配權限、清除垃圾文件、備份配置庫等。質量保證員（即QAG成員）（1）為項目制定質量保證計劃。（2）周期性的開展“過程與產品質量檢查”。（3）跟蹤質量問題，給出質量改進措施。外包管理員（1）挑選最合適的承包商，簽訂外包開發合同。（2）監控外包開發過程，驗收外包開發成果。采購管理員（1）挑選最合適的供應商，簽訂采購合同。（2）驗收采購物品。培訓管理員制定機構（或項目）的培訓計劃，監督該計劃的實施，撰寫培訓評估報告?？蛻舴杖藛T為客戶提供與產品相關的服務（如技術咨詢），快速響應客戶的要求，給客戶一個滿意的解答。產品維護人員（1）糾錯性維護：及時解決用戶遇到的技術故障和消除產品中的缺陷。（2）完善性維護：在資源允許的情況下，不斷改善產品功能與質量。臨時角色職責說明立項建議小組（1）開展立項調查、產品構思和可行性分析，撰寫相應文檔。（2）申請立項，并在立項評審會議上答辯。立項評審委員會由機構領導、各級經理、市場人員、技術專家、財務人員等組成，委員會按少數服從多數原則投票決定是否同意立項。結項評審委員會對項目的有形資產和無形資產進行清算，對項目進行綜合評估，總結經驗教訓等。結項委員會的人員組成與立項評審委員會的類似。技術評審委員會對工作成果進行正式技術評審，盡早地發現工作成果中的缺陷，并幫助開發人員及時消除缺陷。該委員會由項目內外的技術專家組成。配置控制委員會對配置管理各項活動擁有決策權（例如審批計劃，審批變更請求等）。第十四節附則第六十七條 本制度由公司研發部負責解釋和修訂。第六十八條 本制度自發布之日起開始執行。 附件一 立項分析報告文件狀態： 草稿 正式發布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態作者參與者起止日期備注1. 項目介紹1.1. 項目目的提示：用簡練的語言說明本項目“是什么”，“實現什么目的”。描述簡練且清晰。1.2. 項目背景提示：闡述項目背景，重點說明“為什么”會產生本項目。（1）公司的短期、長期發展戰略；（2）業務需求及發展趨勢；（3）技術狀況及發展趨勢；（4）特殊的業務需求等。1.3. 項目范圍提示：根據對現有需求的了解來確定項目基本范圍，說明本系統“應當包含的內容”和“不包含的內容”。2. 項目計劃2.1. 項目團隊提示：說明項目團隊的角色、知識技能要求、建議人選、人數、工作時間，如下表所示。角色知識技能要求建議人選、人數工作時間項目經理需求開發人員 系統設計人員 編程人員 測試人員質量保證人員配置管理人員服務與維護人員2.2. 成本估計內容成本（人民幣）備注人力資源軟硬件資源差旅費會議費接待費2.3. 項目時限：根據用戶要求和公司研發能力設定計劃研發完成時間3. 總結提示：給出清晰的建議結論，便于上級領導決策。附件二 業務需求說明書（業務組編制）文件狀態： 草稿 正式發布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態作者參與者起止日期備注1概述1.1 業務調研人員名單【可選】序號職能部門姓名主管聯系電話備注1.2業務范圍此處描寫總體業務的概要分類。1.3 業務目標從高層或商務利益的角度提出本業務系統的期望目標，以及評價標準。1.4 相關文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括現有規范、標準、批文、引用到的文件、資料等。1.5 業務詞匯表說明：列出本文檔的所引用的專屬領域詞匯、術語等，以便于業務需求的提供者和接收者是建立在一致的業務理解基礎之上的。2 組織結構及業務2.1 業務相關組織結構、人員組織結構說明：如果客戶崗位設置復雜可分別設置，業務組織結構和人員組織結構2.2 組織機構描述2.3 角色職責說明：將業務涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。2.4 管理綜述【可選】說明：主要描述該業務的管理特點和管理模式。例如：2.5 現有業務流程清單【可選】說明：現有業務流程需要考慮，很多新的業務是在已有業務流程基礎上進行重組的。流程編號流程名稱責任部門輔助部門3 業務流程及業務處理描述說明：針對每一項具體的目標業務，描述具體的業務流程，以及相關業務的具體描述。3.1 具體業務流程（系統名稱+編號）對于具體業務流程的命名有規范，對具體流程進行編號，便于形成需求矩陣，同時形成需求的管理和跟蹤。3.1.1業務流程3.1.2業務描述說明：描述具體的業務流程。3.1.3相關業務對象說明：業務對象：業務流程中涉及的單據、報表等。業務對象使用部門對應電子檔案編號3.1.4業務規則及關鍵算法說明：描述業務環節關鍵算法體系。4 假定和約束說明：列出進行本軟件開發工作的假定和約束，例如開發期限等。4.1 運行環境約束4.2 設計約束【可選】說明：開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、第三方產品等。4.3 產品應當遵循的標準或規范【可選】說明：闡述本產品應當遵循什么標準、規范或業務規則，違反標準、規范或業務規則的產品通常不太可能被接受。5 其他5.1 目前核心問題和困難5.2 業務對項目實施的需求和期望【可選】5.3 其他未盡事宜附件三 系統需求規格說明書（IT組編制）文件狀態： 草稿 正式發布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態作者參與者起止日期備注1 引言1.1 目的例如：規定系統的邊界和目標，描述系統的功能性需求和非功能性需求。1.2讀者對象及閱讀建議說明：指明本文檔面向的讀者群，及相應的閱讀意見。1.3文檔范圍【可選】說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統原型，系統測試用例等文檔。1.4 參考文檔說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括計劃任務書、合同、批文、引用到的文件、資料及軟件開發標準等。1.5 術語與縮寫解釋說明：列出本文件中用到的專門術語的定義和縮寫詞的原詞組，并給予解釋，以便于所有讀者達成共識。2 綜合描述2.1 系統背景【可選】說明：介紹系統的預期效果、歷史原因。2.2 問題說明【可選】提供一段說明，總結此項目需要解決的問題。可以采用以下格式：問題是對問題進行說明影響問題影響的干系人問題的后果該問題會導致什么后果成功的解決方案應列出成功解決方案的一些主要優點2.3系統范圍說明：闡述本項目“適用的業務領域”和“不適用的業務領域”，本產品“應當包含的內容”和“不包含的內容”。說清楚系統范圍的好處是：（1）有助于判斷什么是需求，什么不是需求；（2）可以將開發精力集中在產品范圍之內；（3）有助于控制需求的變更。l 完整而準確的定義本產品的干系人；l 明確本產品所影響到的部門和業務；l 用圖表或者文字描述產品的范圍，概要的定義產品的功能。2.4 干系人與用戶說明【可選】2.4.1用戶環境【可選】詳細說明目標用戶的工作環境。以下是幾項建議：該任務由多少人來完成？是否總在變化？一個任務周期需要多長時間？執行每項活動要用多長時間？是否總在變化？是否有特殊的環境約束：移動、戶外、乘機旅行等？目前使用的是哪些系統平臺？以后會使用哪些平臺？還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？在此處可以從業務模型中摘錄一些內容來概述所涉及的任務和角色等等。2.4.2 干系人簡檔【可選】通過在下表中填寫各干系人的相關信息來說明系統中的各個干系人，詳盡的簡檔應包括各種干系人在以下方面的信息：代表誰是此產品的干系人代表？（如在他處已作記錄，則此處為可選。）此處只需填寫姓名。說明對干系人類型的簡要說明。類型介紹干系人的技能特長、技術背景和熟練程度（即權威用戶、業務用戶、專家用戶、初級用戶等）職責列出干系人對所開發的系統負有的關鍵職責，即他們作為干系人的利益。使用頻率該干系人使用系統的頻率意見/問題在此處列出會阻礙成功的問題以及任何其他相關信息。2.4.3關鍵的干系人/用戶需要列出干系人認為現有解決方案存在的關鍵問題。對于列出的每個問題，需澄清以下要點：為什么會出現這一問題？目前如何解決該問題？干系人需要什么樣的解決方案？務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法表明，必須解決的問題與干系人或用戶希望解決的問題大有不同。2.5 目標業務模型【可選】說明：新系統業務模型描述，如有相應業務模型材料了，可作為需求規格說明書的輸入參考資料。2.6 功能摘要總結該產品將提供的主要優點和特性，而不必涉及每個功能的細節。對功能加以組織，使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。2.7 功能清單及重要程度說明說明：功能名稱、功能描述、重要程度。重要程度，以ABC三類來表示：A：核心功能；B：輔助功能；C：外圍功能；級別，按照繼承關系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注2.8 功能與業務對照關系表說明：業務組為主編寫業務需求，業務需求提交至信息技術組后，由信息技術組建立目標系統業務模型并與業務組進行確認（本操作可選，也可由信息技術組與開發商合作建立），目標業務模型作為系統需求的輸入，由信息技術組與開發商合作撰寫和評審系統需求規格書明書。業務需求目標系統業務活動（可選）功能名稱2.9 假定和約束說明：列出進行本軟件開發工作的假定和約束，例如：開發語言、開發期限等。格式限制說明：本項將指定由現有的標準或規則派生的要求。例如：報表格式；數據命名；財務處理；審計追蹤，等等。硬件限制說明：本項包括在各種硬件約束下運行的軟件要求，例如，應該包括：硬件配置的特點（接口數，指令系統等）；內存儲器和輔助存儲器的容量。2.9.1運行環境約束說明：硬件設備、支持軟件、接口、控制等方面的約束名稱詳細要求2.9.2設計約束【可選】說明：開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、第三方產品等。2.9.3產品應當遵循的標準或規范說明：闡述本產品應當遵循什么標準、規范或業務規則，違反標準、規范或業務規則的產品通常不太可能被接受。3 具體需求3.1功能需求3.1.1具體功能3.1.1.1內容說明：對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需求。3.2 非功能需求3.2.1 外部接口3.2.1.1用戶接口說明：提供用戶使用軟件產品時的接口需求。例如，如果系統的用戶通過顯示終端進行操作，就必須指定如下要求：a對屏幕格式的要求說明：對界面上的各對象、類型、寬度、取值范圍、數據來源、能否為空等屬性進行描述。b報表或菜單的頁面打印格式和內容c輸入輸出的需求說明：解釋各輸入輸出數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對軟件的數據輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。d程序功能鍵的可用性說明：快捷鍵定義等。3.2.1.2 硬件接口【可選】說明：要指出軟件產品和系統硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什么樣的設備，如何支撐這些設備，有何約定。3.2.1.3軟件接口【可選】說明：在此要指定需使用的其他軟件產品（例如，數據管理系統、操作系統或數學軟件包），以及同其他應用系統之間的接口。對每一個所需的軟件產品，要提供如下內容：名字、助記符、規格說明號、版本號、來源。對于每一個接口，這部分應說明與軟件產品相關的接口軟件的目的，并根據信息的內容和格式定義接口，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。【接口定義】下表是對一些接口的具體描述:接口名稱接口描述填寫接口完成的任務接口類型填寫是輸入接口（inbound）還是輸出接口（outbound）源系統填寫接口輸入方系統或部件目標系統填寫接口輸出方系統或部件廠商提供/客戶化開發文件類型填寫文件類型；若通過數據庫表來交互，請指明數據庫及表名文件數量峰值數據量頻度填寫數據處理的頻度復雜度批處理 /人工填寫接口數據的驅動模式是人工（manual）還是自動(automatic)，還是都支持接口類型填寫是實時接口還是批量接口等【其他系統詳細信息】說明：列出所有與接口交互的外圍系統的詳細信息。包括輸入、輸出系統等系統填寫與接口交互的系統名稱系統類型填寫是接口的數據源系統(source)還是目標系統(object)數據庫填寫交互系統使用的數據庫及版本軟件填寫交互系統的軟件名稱架構類型交互系統的架構類型是B/S 還是C/S。位置填寫該軟件在交互軟件體系中所出的位置技術支持填寫交互系統的開發商和支持商功能支持填寫具體的支持商或技術團隊數據歸屬【接口隸屬系統的詳細信息可選 】系統填寫接口隸屬系統的名稱模塊隸屬于具體的模塊名稱數據庫隸屬系統的數據庫及版本負責人控制報告【接口配置】（1）接口基礎信息配置說明：接口基礎信息的配置項目，描述配置的方式。（2）接口運行參數配置說明：接口運行參數的配置方式和步驟?！酒渌渲每蛇x 】說明：外圍系統或相關模塊的配置。3.2.1.4通信接口【可選】說明：指定各種通信接口。例如，局部網絡的協議等等。3.2.2 其他非功能性需求說明：下表中的各種需求，可根據實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細解釋。名稱詳細要求靜態數值需求動態數值需求精度時間特性要求可用性可靠性可維護性安全性可移植性可擴展性兼容性3.2.2.1 靜態數值需求說明：支持的終端數；支持并行操作的用戶數。3.2.2.2 動態數值需求說明：欲處理的事務和任務的數量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數據總量。3.2.2.3 精度 說明:對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。3.2.2.4時間特性要求 說明：對于該軟件的時間特性要求，如對：a響應時間；b更新處理時間；c數據的轉換和傳送時間；d解題時間等要求。3.2.2.5 數據管理要求【可選】說明：需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求做出估算。3.2.2.6 可用性指出普通用戶和高級用戶要高效地執行特定操作所需的培訓時間，指出典型任務的可評測任務次數或根據用戶已知或喜歡的其他系統確定新系統的可用性需求性能3.2.2.7可靠性指出可用時間百分比 ( xx.xx%)、使用小時數、維護訪問權、降級模式操作等。平均故障間隔時間 (MTBF)。平均修復時間 (MTTR)系統在發生故障后可以暫停運行的時間。指出系統輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。3.2.3文檔需求說明：主要是在線用戶手冊與幫助系統，也包括其他的文檔3.2.4 第三方產品【可選】說明：使用到的第三方產品相關的 使用許可、使用限制、接口標準。3.3 數據字典說明：把相關的數據抽取出來統一維護，在其他章節如有類似信息描述，則關聯到數據字典的相關部分并加輔助說明，如：引用到的字段等。4 補充資料【可選】4.1待確定的問題列表【可選】需求標題1調查方式調查人調查對象時間、地點需求信息記錄 附件四 需求變更申請記錄號： 項 目：類 型：開發項目項目負責人：變更申請人：申請部門：申請日期：變更內容變更的內容及其理由說明變更的內容及變更的理由，如果變更為業務組提出，則業務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；變更的系統及版本說明變更所涉及的工作產品及其當前版本，如果變更為業務組提出，則業務組填寫；如果變更為為信息技術組提出，則信息技術組填寫；對業務及其接口的影響分析需求變更引起的業務變更、業務接口的變更，業務組填寫業務負責人意見：同意 不同意 簽字： 日期：變更結果變更分析對相關的資源影響分析需求變更對人員、開發設備和目標設備的影響，僅信息技術組填寫風險分析分析需求變更的風險，僅信息技術組填寫對其他系統或接口的影響分析需求變更引起的系統變更、其他系統或接口的變更，僅信息技術組填寫對開發工作量、進度和成本影響估計需求變更對開發工作量和進度的影響，需說明本次變更工作量/成本是否超過本項目總開發工作量/總成本的1%？僅信息技術組填寫研發部審批意見研發部負責人意見：同意 不同意 指定驗證人員：簽字： 日期：處經理意見：同意 不同意 匯報上級簽字： 日期：上級經理意見：同意 不同意 簽字： 日期：變更結果變更的系統及版本說明變更后的工作產品簽字： 日期：變更驗證驗證變更結果完整性是 否正確性是 否附加變更是 否版本和名稱是 否驗證人意見： 符合要求 不符合要求簽字： 日期：附件五 項目計劃書文件狀態： 草稿 正式發布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態作者參與者起止日期備注1 文檔介紹1.1 文檔目的1.2文檔范圍1.3參考文獻提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：標識符 作者，文獻名稱，出版單位（或歸屬單位），日期例如：AAA 作者，立項建議書，機構名稱，日期1.5 術語與縮寫解釋縮寫、術語解 釋2 項目介紹2.1項目范圍提示：（1）用簡練的語言說明本項目“是什么”，“說明用途”。（2）說明本項目“應當包含的內容”和“不包含的內容”。2.2項目目標提示：給出“清晰的”、“可實現”、“可驗證”的目標。2.3客戶與最終用戶介紹提示：請說明本項目的客戶、用戶及其相關責任人是誰，描述最終用戶的特征。2.4 約束提示：（1）請說明在項目開發過程中應當遵循的標準或規范（2）請說明相關項目可能對本項目造成的影響。（3）說明一些假設和依賴。3 項目過程定義3.1軟件生命周期模型提示：簡要描述、繪制本項目的軟件生命周期模型。3.2項目規范提示：描述項目需遵循的規范，例如：編碼規范。此處可以表現為編碼規范的鏈接。3.3方法與工具提示：說明在過程中將采用的方法與工具。例如采用Rational Rose進行面向對象分析與設計，采用Visual SourceSafe進行配置管理，采用Microsoft Office制作文檔。方法與工具用途Visual SourceSafe配置管理4 里程碑計劃序號里程碑名稱開始日期結束日期工作成果備注5 資源計劃5.1人力資源計劃提示：制定本項目的角色職責表，并為已知的項目成員分配角色（一個人可以兼多個角色）。角色職責人員姓名工作說明高層領導項目經理需求分析員系統設計員程序員測試員5.2 軟硬件資源計劃提示：分析項目開發、測試、運行所需的軟硬件資源和關鍵計算機資源（會影響軟件產品的性能的CPU、內存、帶寬等內容），主要內容包括：l 資源級別（分為“關鍵”、“普通”兩種）l 詳細配置l 獲取方式（如“已經存在”、“可以借用”或“需要購買”等）與獲取時間l 使用說明（如“誰”在“什么”時候使用）軟硬件資源名稱級別詳細配置獲取方式與時間使用說明關鍵關鍵普通6 文檔交付列表序號交付文檔名稱交付日期備注7 風險管理計劃提示：以下是各個列標題的解釋。約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。風險級別：確定風險的嚴重性、可能性、風險系數風險描述：緩解方案或者應急計劃。風險編號風險級別風險描述緩解方案應急計劃嚴重性(1-5)可能性(%)風險系數(嚴重性*可能性)8 溝通計劃甲方代表乙方代表溝通方式溝通頻率/時間期望結果9 附件l 項目進度計劃n 進度表提示：制定項目開發的進度表（建議給出項目里程碑計劃）。例如：編號里程碑名稱預計結束時間備注需求調研完成項目計劃完成需求分析完成概要設計完成詳細設計完成實現完成集成測試完成系統測試完成用戶驗收測試完成試運行結束項目驗收附件六 項目計劃變更說明項目名稱申請日期項目計劃變更申請申請變更的項目計劃輸入名稱，版本，完成日期等信息變更的內容及其理由評估計劃變更將對項目造成的影響項目負責人簽字變更申請的審批意見處經理審批審批意見：簽字，日期研發部負責人審批審批意見：簽字，日期業務部門意見審批意見：簽字，日期更改項目計劃變更后的項目計劃輸入名稱，版本，完成日期等信息項目負責人簽字附件七 設計說明書文件狀態： 草稿 正式發布 正在修改文件標識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態作者參與者起止日期備注1引言1.1編寫目的說明編寫這份詳細設計說明書的目的，指出預期的讀者。1.2背景說明：待開發軟件系統的名稱；本項目的任務提出者、開發者、用戶和運行該程序系統的計算中心。1.3定義列出本文件中用到專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出有關的參考資料，如：本項目的經核準的計劃任務書或合同、上級機關的批文；屬于本項目的其他已發表的文件；本文件中各處引用到的文件資料，包括所要用到的軟件開發標準。列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠取得這些文件的來源。2程序系統的結構用一系列圖表列出本程序系統內的每個程序（包括每個模塊和子程序）的名稱、標識符和它們之間 的層次結構關系。3程序1（標識符）設計說明從本章開始，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對一般情況的。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內容往往與它所隸屬的上一層 模塊的對應條目的內容相同，在這種情況下，只要簡單地說明這一點即可。3.1程序描述給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，并且，還要說明本程序的特點（如 是常駐內存還是非常駐？是否子程序？是可重人的還是不可重人的？有無覆蓋要求？是順序處理還是并發處理等）。3.2功能說明該程序應具有的功能，可采用IPO圖（即輸入一處理一輸出圖）的形式。3.3性能說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。3.4輸人項給出對每一個輸入項的特性，包括名稱、標識、數據的類型和格式、數據值的有效范圍、輸入的方式。數量和頻度、輸入媒體、輸入數據的來源和安全保密條件等等。3.5輸出項給出對每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效范圍，輸出的形式、數量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。3.6算法詳細說明本程序所選用的算法，具體的計算公式和計算步驟。3.7流程邏輯用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。3.8接口用圖的形式說明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序，說明參數賦值和調用方式，說明與本程序相直接關聯的數據結構（數據庫、數據文卷）。3.9存儲分配根據需要，說明本程序的存儲分配。3.10注釋設計說明準備在本程序中安排的注釋，如：加在模塊首部的注釋；加在各分枝點處的注釋；對各變量的功能、范圍、缺省條件等所加的注釋；對使用的邏輯所加的注釋等等。3.11限制條件