軟件開發(fā)治理制度第一節(jié)總則第一條 為標準自有軟件研發(fā)以及外包軟件的治理工作，特制定本制度。本制度適用于公司總公司軟件研發(fā)與治理，分公司參照執(zhí)行。其次條第三條

本制度中軟件開發(fā)指系統(tǒng)開發(fā)和現(xiàn)有系統(tǒng)重大改造。本制度中自行開發(fā)是指主要依靠公司自身的治理、業(yè)務和技術力氣進展系統(tǒng)設計、軟件開發(fā)、集成和相關的技術支持工作，一般僅向外購置有關的IT〔合作商〕共同ITIT系統(tǒng)的日常支持由研發(fā)部和合作商共同擔當，研發(fā)負責內(nèi)部支持，合作商負責IT承包給某家專業(yè)公司〔可以是專業(yè)的IT公司或詢問公司等〕，由該公司〔承包商〕負責應用工程的實施。第四條軟件開發(fā)遵循工程治理和軟件工程的根本原則。工程治理涉及立項治理、工程打算和監(jiān)控、配置治理、合作開發(fā)治理和結項治理。軟件工程涉及需求治理、系統(tǒng)設計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、用戶承受測試、試運行、系統(tǒng)驗收、系統(tǒng)上線和數(shù)據(jù)遷移。第五條除特別指定，本制度中工程組包括業(yè)務組〔營銷部、運維部、IT〔研發(fā)部和合作開發(fā)商。其次節(jié)立項治理第六條 提出開發(fā)需求的營銷部、運維部等業(yè)務部門參與公司層面立項，研發(fā)部進展立項的技術可行性分析，共同編寫《立項分析報告》〔附件一開展前期籌備工作《立項分析報告》應明確工程的范圍和邊界。第七條 應用系統(tǒng)主要使用部門將《立項分析報告》上交公司進展立項審批，以保證系統(tǒng)工程與公司整體策略相全都。第八條第九條第十條第十一條第十二條第十三條第十四條第十五條

《立項分析報告》得到批準后，成立工程組〔假設是外包開發(fā)，則成立外包商工程組；假設是合作開發(fā)，則與外包商共同成立合作開發(fā)工程組，以，工程組應包括業(yè)務組〔由公司相關業(yè)務部門組成〕和IT組〔自行開發(fā)為研發(fā)部；外包開發(fā)為外包商成員；合作開發(fā)為研發(fā)部和外包商成員。公司委派一名員工負責監(jiān)視工程的進度，進展工程治理工作，確保開發(fā)能準時完成并能滿足業(yè)務需要。工程組人員的選擇應滿足工程IT來勝任工程各方面的工作。第三節(jié)需求分析立項后業(yè)務組對用戶需求進展匯總整理，出具《業(yè)務需求說明書》〔附件二，并確保《業(yè)務需求說明書》中包含了全部的業(yè)務需求。《業(yè)務需求說明書》經(jīng)系統(tǒng)使用單位〔用戶〕確認，作為業(yè)務需求基線。IT組在獲得《業(yè)務需求說明書》后，提出技術需求和解決方案，并對系統(tǒng)進展定義，出具《系統(tǒng)需求規(guī)格說明書》〔附件三書》需具體列出業(yè)務對系統(tǒng)的要求〔界面、輸入、輸出、治理功能、安全需求、運作模式、關鍵指標等系統(tǒng)需求規(guī)格說明書》需要由業(yè)務組提交給用戶相關業(yè)務流程負責人確認。〔附件四，IT組長審批后交給業(yè)務組與用戶確認方可實施。工程組應對需求變更影響到的文檔準時更。第四節(jié)工程打算和監(jiān)控軟件開發(fā)承受工程形式進展治理。工程經(jīng)理〔監(jiān)理〕負責整個工程的打算、組織、領導和掌握。需求分析過程中，工程經(jīng)理〔監(jiān)理〕〔附件五，包括具體任務描述和工程進度表等。IT〔監(jiān)理〕制定IT〔監(jiān)理〕對工程打算執(zhí)行狀況進展監(jiān)控，確保工程按打算完成。第十六條第十七條第十八條第十九條其次十條其次十一條其次十二條其次十三條其次十四條其次十六條

工程打算需要變更時，工程經(jīng)理〔監(jiān)理〕〔附件六，并提交公司主管領導審批，通過審批后，交給業(yè)務組組長和IT長執(zhí)行。第五節(jié)系統(tǒng)設計系統(tǒng)設計應分為概要設計和具體設計，系統(tǒng)設計要遵循完備性、全都性、擴展性、牢靠性、安全性、可維護性等原則。在系統(tǒng)設計階段中，用戶應充分參與，確保系統(tǒng)設計能滿足系統(tǒng)需求。工程組進展具體設計，出具《設計說明書》〔附件七〕和《單元測試用例》〔附件八明。公司主管領導組織相關人員對概要設計進展評審，出具《設計評審報〔附件九。業(yè)務組組長和IT組組長應參與此評審并對評審意見簽字確認。設計評審均以《業(yè)務需求說明書》和《系統(tǒng)需求規(guī)格說明書》為依據(jù)，確保系統(tǒng)設計滿足全部需求。對已確認通過的系統(tǒng)設計進展修改需獲得治理部門、業(yè)務組組長和IT組組長的審批前方可進展。對系統(tǒng)設計的修改的文檔須由文檔治理人員進展歸檔治理。第六節(jié)系統(tǒng)實現(xiàn)工程組依據(jù)《設計說明書》制定系統(tǒng)實現(xiàn)打算，并提交工程經(jīng)理〔監(jiān)理〕對打算可行性進展審批。系統(tǒng)實現(xiàn)包括程序編碼、單元測試和集成測試。工程組保證開發(fā)、測試和訪問環(huán)境獨立，為各環(huán)境建立訪問權限掌握機制，并明確工程成員的職責分工。對開發(fā)環(huán)境、測試環(huán)境與訪問環(huán)境在物理或規(guī)律方面應當做到隔離；假設環(huán)境的分隔是通過規(guī)律形式實現(xiàn)的，應定期檢查網(wǎng)絡設置。工程組對已授權訪問環(huán)境的人員進展具體記錄，并對該記錄進展定期檢查，確保只有經(jīng)授權的人員才能訪問。工程組進展單元測試和集成測試，測試人員簽字確認測試結果。第七節(jié)系統(tǒng)測試和用戶測試其次十七條 工程組制定《系統(tǒng)/用戶測試打算〔附件十，并提交工程經(jīng)理〔監(jiān)理〕打算可行性進展審批。其次十八條 《系統(tǒng)/用戶測試打算》必需定義測試標準，并明確各種測試的測試步驟和需要的系統(tǒng)設置要求。其次十九條 工程組向數(shù)據(jù)擁有部門申請獵取測試用業(yè)務數(shù)據(jù)的使用權，對獵取的數(shù)據(jù)進展嚴格的訪問掌握，確保只有相關工程人員才能訪問及使用。第三十條第三十一條第三十二條第三十三條第三十四條第三十六條第三十七條

工程組負責測試數(shù)據(jù)預備，測試用數(shù)據(jù)要足夠模擬使用環(huán)境中的實際數(shù)據(jù)。對已評定為敏感信息的數(shù)據(jù)進展敏感性處理和保護。IT組或合作開發(fā)商建立測試環(huán)境進展系統(tǒng)測試。在系統(tǒng)測試中對系統(tǒng)內(nèi)部各模塊之間的接口和與其他系統(tǒng)的接口進展充分測試。出具《系統(tǒng)測試〔附件十一，測試人員簽字確認測試結果。系統(tǒng)測試通過后，IT組協(xié)作業(yè)務組建立用戶測試環(huán)境，業(yè)務組依據(jù)用戶測〔附件十一IT工程組完成系統(tǒng)幫助文檔〔其中包括《用戶操作手冊》和《安裝維護手。凡涉及應用系統(tǒng)的變更，應對系統(tǒng)幫助文檔準時更。第八節(jié)試運行系統(tǒng)主要使用部門依據(jù)工程規(guī)模及影響打算試運行策略。〔附件十二道和職責分工。工程組聯(lián)合試運行單位進展相關系統(tǒng)部署工作，預備培訓資料，對相關用戶和信息技術人員進展培訓。用戶培訓的完成度應為實施后評估的指標之一。工程組依據(jù)《試運行打算》進展系統(tǒng)轉換和數(shù)據(jù)遷移。系統(tǒng)轉換前，檢查系統(tǒng)環(huán)境，確保運行環(huán)境能滿足應用系統(tǒng)的需要。系統(tǒng)轉換時必需具體記錄原系統(tǒng)中的重要參數(shù)、設置等系統(tǒng)信息，并填寫試運行報告相關內(nèi)容。系統(tǒng)參數(shù)、設置的轉換工作作為系統(tǒng)上線的驗收的評估指標之一。第三十八條 數(shù)據(jù)遷移前，應制定具體的《數(shù)據(jù)遷移打算》〔附件十三《數(shù)據(jù)遷移打算》中應包含遷移方案、測試方案、數(shù)據(jù)定義，舊數(shù)據(jù)比照表、遷移時間、回退打算等信息。數(shù)據(jù)遷移打算需經(jīng)工程經(jīng)理〔監(jiān)理〕和主管領導簽字審批。第三十九條 數(shù)據(jù)遷移后，工程組對數(shù)據(jù)遷移的完整性和準確性作出檢查，出具《數(shù)據(jù)遷移報告〔附件十四其中包括數(shù)據(jù)來源、轉換前狀態(tài)、轉換后狀態(tài)，數(shù)據(jù)遷移負責人、對完整性檢查狀況、對準確性檢查狀況等內(nèi)容。各相關部門驗收轉換結果后在該報告上簽字確認。第四十條第四十一條第四十二條第四十三條第四十四條第四十五條第四十六條第四十七條

系統(tǒng)轉換和數(shù)據(jù)遷移由試運行單位業(yè)務部門和公司主管領導共同監(jiān)視并進展驗收。系統(tǒng)轉換和數(shù)據(jù)遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位辦公室把系統(tǒng)運行狀況〔系統(tǒng)資源使用，反響速度等〕記錄到試運行報告中。必要時，工程組應依據(jù)系統(tǒng)運行狀況對應用系統(tǒng)進展優(yōu)化。〔附件十五。此報告應由工程組和試運行單位簽字確認，并提交公司主管領導批閱。公司主管領導批閱試運行結果，打算試運行完畢或延期。第九節(jié)系統(tǒng)驗收系統(tǒng)主要用戶單位及公司工程組聯(lián)合組成獨立系統(tǒng)驗收小組，也可授權原工程組作為驗收小組。驗收小組從功能需求及技術需求層面對系統(tǒng)進展綜合評估。〔附件十六〕提交系統(tǒng)主要使用部門和公司批閱。見。第十節(jié)系統(tǒng)上線系統(tǒng)上線應遵循穩(wěn)妥、可控、安全的原則。通常狀況下，系統(tǒng)上線包含數(shù)據(jù)遷移工作。〔附件十七線打算得到批準后才能開頭部署上線工作。第四十九條 《系統(tǒng)上線打算》內(nèi)容應包括但不限于：1、部署方式和資源安排〔包括人力資源及效勞器資源；2、上線工作時間表；3、上線操作步驟以及問題處理步驟；4、工程階段性里程碑和成果匯報〔工程執(zhí)行狀態(tài)的批閱、進度安排等；5、數(shù)據(jù)遷移的需求和實施打算；6、完整可行的應急預案和“回退”打算；7、用戶培訓打算〔包括：培訓打算、培訓手冊、培訓考核等；8、總公司下發(fā)的系統(tǒng)標準參數(shù)配置。第五十條第五十一條

上線單位在上線初期需加強日常運行狀態(tài)監(jiān)控，消滅問題時應準時處理，對重大問題應啟動緊急預案。在完成上線后要填寫《系統(tǒng)驗收評估報告》〔附件十八定性、接口問題、權限問題、業(yè)務操作影響度、問題處理狀況、備份、批處理等。上線單位治理層要對《系統(tǒng)驗收評估報告》進展審批簽字。公司主管領導批準結項后，業(yè)務組和IT組將整理的文檔提交各自部門統(tǒng)一治理。第十一節(jié)合作開發(fā)治理第五十四條第五十五條第五十七條第五十八條第五十九條第六十條

合作開發(fā)商的選擇應遵循公司相關規(guī)定，合作商資質(zhì)認定參見第三方治理制度。合作開發(fā)商必需遵循公司《軟件開發(fā)治理制度工程經(jīng)理同合作開發(fā)商明確規(guī)定工程變更的范圍和處理方式，重點關注需求和設計變更。工程經(jīng)理負責監(jiān)控合作開發(fā)商的工程治理及軟件開發(fā)活動。合作開發(fā)商應按打算定期向工程經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，合作開發(fā)商需準時向工程經(jīng)理匯報。IT工程組同合作開發(fā)商商定驗收的標準和方法。以上各要求需要在開發(fā)合同中明確。第十二節(jié)外包開發(fā)治理第六十一條 立項申請得到公司主管領導的審批后，選定開發(fā)商，簽訂外包開發(fā)合同。第六十二條 工程經(jīng)理負責監(jiān)控外包開發(fā)商的工程治理及軟件開發(fā)活動。外包開發(fā)商應按打算定期向工程經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，外包開發(fā)商需準時向工程經(jīng)理匯報。第六十三條 工程經(jīng)理監(jiān)控外包開發(fā)商的質(zhì)量保證過程。第六十四條 工程組同外包開發(fā)商商定驗收的標準和方法。第六十五條 以上各要求需要在開發(fā)合同中明確。第十三節(jié)角色與職責表第六十六條主要角色及其職責如下表所示。企業(yè)在應用時，可以將各個角色映射到企業(yè)原有的崗位上，也可以依據(jù)角色建立的崗位。一個人可以被賜予多個角色，視具體狀況而定。常設角色軟件工程過程組機構 〔SEPG〕

職責簡述制定適合于本機構的過程標準。在機構范圍內(nèi)推廣該標準〔如培訓、考核〕過程力量等。過程 〔1〕監(jiān)視標準的實施，確保全部工程以及相關部門準照標準改進 質(zhì)量保證小組 開展工作。角色 〔QAG〕 〔2〕分析并解決機構內(nèi)存在的共性質(zhì)量問題，協(xié)組SEPG完善標準。〔1〕是機構內(nèi)全部工程的主管，對立項治理和結項治理有最機構領導 終決策權。工程 〔2〕監(jiān)視工程經(jīng)理的工作，審批工程經(jīng)理的各種申請。治理過程角色 工程經(jīng)理需求分析員

向機構領導匯報工作。是工程規(guī)劃、工程監(jiān)控、風險治理和需求治理過程域的負責人。監(jiān)視工程成員的工作，審批工程成員的各種申請。調(diào)查、分析并定義需求，撰寫相應的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。項目 依據(jù)需求文檔設計軟件系統(tǒng)的體系構造、用戶界面、數(shù)據(jù)研發(fā) 系統(tǒng)設計師過程 程序員角色測試員

庫、模塊等，并撰寫相應的設計文檔。依據(jù)系統(tǒng)設計文檔，編寫軟件系統(tǒng)的代碼。隨時測試和檢查自己的代碼，準時消退代碼中的缺陷。從事單元測試、集成測試和系統(tǒng)測試，主要工作包括制定測試打算、設計測試用例、執(zhí)行測試和撰寫測試報告。〔1〕為工程制定《配置治理打算配置治理員 〔2〕創(chuàng)立并維護配置庫，如安排權限、去除垃圾文件、備份配置庫等。質(zhì)量保證員外包治理員機構支撐 選購治理員

為工程制定《質(zhì)量保證打算周期性的開展“過程與產(chǎn)品質(zhì)量檢查跟蹤質(zhì)量問題，給出質(zhì)量改進措施。選擇最適宜的承包商，簽訂外包開發(fā)合同。監(jiān)控外包開發(fā)過程，驗收外包開發(fā)成果。選擇最適宜的供給商，簽訂選購合同。過程 〔2〕驗收選購物品。角色培訓治理員客戶效勞人員產(chǎn)品維護人員

制定機構〔或工程〕的要求，給客戶一個滿足的解答。糾錯性維護：準時解決用戶遇到的技術故障和消退產(chǎn)品中的缺陷。完善性維護：在資源允許的狀況下，不斷改善產(chǎn)品功能與質(zhì)量。臨時角色 職責說明開展立項調(diào)查、產(chǎn)品構思和可行性分析，撰寫相應文立項建議小組 檔。申請立項，并在立項評審會議上辯論。立項評審委員會

由機構領導、各級經(jīng)理、市場人員、技術專家、財務人員等組成，委員會按少數(shù)聽從多數(shù)原則投票打算是否同意立項。對工程的有形資產(chǎn)和無形資產(chǎn)進展清算，對工程進展綜合評結項評審委員會 估，總結閱歷教訓等。結項委員會的人員組成與立項評審委員會的類似。對工作成果進展正式技術評審，盡早地覺察工作成果中的缺技術評審委員會 陷，并幫助開發(fā)人員準時消退缺陷。該委員會由工程內(nèi)外的技術專家組成。配置掌握委員會

對配置治理各項活動擁有決策權〔例如審批打算，審批變更懇求等。第十四節(jié)附則第六十七條 本制度由公司研發(fā)部負責解釋和修訂。第六十八條 本制度自公布之日起開頭執(zhí)行。附件一 立項分析報告文件狀態(tài)：文件狀態(tài)：文件標識：[√]草稿當前版本：[]正式公布作者：[]正在修改完成日期：版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注工程介紹工程目的工程背景提示：闡述工程背景，重點說明“為什么”會產(chǎn)生本工程。公司的短期、長期進展戰(zhàn)略；業(yè)務需求及進展趨勢；技術狀況及進展趨勢；特別的業(yè)務需求等。工程范圍提示：依據(jù)對現(xiàn)有需求的了解來確定工程根本范圍，說明本系統(tǒng)“應當包含的內(nèi)容”和“不包含的內(nèi)容工程打算工程團隊提示：說明工程團隊的角色、學問技能要求、建議人選、人數(shù)、工作時間，如下表所示。工程經(jīng)理

學問技能要求 建議人選、人數(shù) 工作時間系統(tǒng)設計人員編程人員系統(tǒng)設計人員編程人員測試人員質(zhì)量保證人員配置治理人員效勞與維護人員……本錢估量內(nèi)容內(nèi)容本錢〔人民幣〕備注人力資源軟硬件資源差旅費…工程時限：依據(jù)用戶要求和公司研發(fā)力量設定打算研發(fā)完成時間總結提示：給出清楚的建議結論，便于上級領導決策。附件二 業(yè)務需求說明書〔業(yè)務組編制〕文件狀態(tài)：文件狀態(tài)：文件標識：[√]草稿當前版本：[]正式公布作者：[]正在修改完成日期：版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注概述業(yè)務調(diào)研人員名單【可選】序號序號職能部門姓名主管聯(lián)系備注業(yè)務范圍此處描寫總體業(yè)務的概要分類。業(yè)務目標從高層或商務利益的角度提出本業(yè)務系統(tǒng)的期望目標，以及評價標準。相關文檔說明：列出本文檔的全部參考文獻〔可以是非正式出版物〕，包括現(xiàn)有標準、標準、批文、引用到的文件、資料等。業(yè)務詞匯表說明：列出本文檔的所引用的專屬領域詞匯、術語等，以便于業(yè)務需求的供給者和接收者是建立在全都的業(yè)務理解根底之上的。組織構造及業(yè)務業(yè)務相關組織構造、人員組織構造說明：假設客戶崗位設置簡單可分別設置，業(yè)務組織構造和人員組織構造組織機構描述角色職責說明：將業(yè)務涉及的具體人員進展肯定程度的分類和抽象，描述該抽象角色的操作職責。治理綜述【可選】說明：主要描述該業(yè)務的治理特點和治理模式。例如：現(xiàn)有業(yè)務流程清單【可選】說明：現(xiàn)有業(yè)務流程需要考慮，很多的業(yè)務是在已有業(yè)務流程根底上進展重組的。流程編號流程編號流程名稱責任部門關心部門業(yè)務流程及業(yè)務處理描述說明：針對每一項具體的目標業(yè)務，描述具體的業(yè)務流程，以及相關業(yè)務的具體描述。具體業(yè)務流程〔系統(tǒng)名稱+編號〕對于具體業(yè)務流程的命名有標準，對具體流程進展編號，便于形成需求矩陣，同時形成需求的治理和跟蹤。業(yè)務流程業(yè)務描述說明：描述具體的業(yè)務流程。相關業(yè)務對象說明：業(yè)務對象：業(yè)務流程中涉及的單據(jù)、報表等。業(yè)務對象業(yè)務對象使用部門對應電子檔案編號業(yè)務規(guī)章及關鍵算法說明：描述業(yè)務環(huán)節(jié)關鍵算法體系。假定和約束說明：列出進展本軟件開發(fā)工作的假定和約束，例如開發(fā)期限等。運行環(huán)境約束設計約束【可選】說明：開發(fā)過程中必需使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術、第三方產(chǎn)品等。產(chǎn)品應當遵循的標準或標準【可選】說明：闡述本產(chǎn)品應當遵循什么標準、標準或業(yè)務規(guī)章，違反標準、標準或業(yè)務規(guī)章的產(chǎn)品通常不太可能被承受。其他目前核心問題和困難業(yè)務對工程實施的需求和期望【可選】其他未盡事宜附件三 系統(tǒng)需求規(guī)格說明書〔IT組編制〕文件狀態(tài)：文件狀態(tài)：文件標識：[√]草稿當前版本：[]正式公布作者：[]正在修改完成日期：版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注引言目的例如：規(guī)定系統(tǒng)的邊界和目標，描述系統(tǒng)的功能性需求和非功能性需求。讀者對象及閱讀建議說明：指明本文檔面對的讀者群，及相應的閱讀意見。文檔范圍【可選】說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。參考文檔說明：列出本文檔的全部參考文獻〔可以是非正式出版物〕，包括打算任務書、合同、批文、引用到的文件、資料及軟件開發(fā)標準等。術語與縮寫解釋說明：列出本文件中用到的特地術語的定義和縮寫詞的原詞組，并賜予解釋，以便于全部讀者達成共識。綜合描述系統(tǒng)背景【可選】說明：介紹系統(tǒng)的預期效果、歷史緣由。問題說明【可選】供給一段說明，總結此工程需要解決的問題。可以承受以下格式：問題是問題是[對問題進展說明]影響[問題影響的干系人]問題的后果[該問題會導致什么后果]成功的解決方案[應列出成功解決方案的一些主要優(yōu)點]系統(tǒng)范圍說明：闡述本工程“適用的業(yè)務領域”和“不適用的業(yè)務領域”，本產(chǎn)品“應當包含的內(nèi)有助于推斷什么是需求，什么〔2〕可以將開發(fā)精力集中在產(chǎn)品范圍之內(nèi)〔〕有助于掌握需求的變更。完整而準確的定義本產(chǎn)品的干系人；明確本產(chǎn)品所影響到的部門和業(yè)務；用圖表或者文字描述產(chǎn)品的范圍，概要的定義產(chǎn)品的功能。干系人與用戶說明【可選】用戶環(huán)境【可選】具體說明目標用戶的工作環(huán)境。以下是幾項建議：該任務由多少人來完成？是否總在變化？一個任務周期需要多長時間？執(zhí)行每項活動要用多長時間？是否總在變化？是否有特別的環(huán)境約束：移動、戶外、乘機旅行等？目前使用的是哪些系統(tǒng)平臺？以后會使用哪些平臺？還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？在此處可以從業(yè)務模型中摘錄一些內(nèi)容來概述所涉及的任務和角色等等。干系人簡檔【可選】通過在下表中填寫各干系人的相關信息來說明系統(tǒng)中的各個干系人，詳盡的簡檔應包括各種干系人在以下方面的信息：代表代表[誰是此產(chǎn)品的干系人代表？〔如在他處已作記錄，則此處為可選。〕此處只需填寫姓名。]說明[對干系人類型的簡要說明。]類型[介紹干系人的技能特長、技術背景和嫻熟程度〔即權威用戶、業(yè)務用戶、專家用戶、初級用戶等〕]職責[列出干系人對所開發(fā)的系統(tǒng)負有的關鍵職責，即他們作為干系人的利益。]使用頻率[該干系人使用系統(tǒng)的頻率]意見/問題[在此處列出會阻礙成功的問題以及任何其他相關信息。]關鍵的干系人/用戶需要列出干系人認為現(xiàn)有解決方案存在的關鍵問題。對于列出的每個問題，需澄清以下要點：為什么會消滅這一問題？目前如何解決該問題？干系人需要什么樣的解決方案？務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法說明，必需解決的問題與干系人或用戶期望解決的問題大有不同。目標業(yè)務模型【可選】說明：系統(tǒng)業(yè)務模型描述，如有相應業(yè)務模型材料了，可作為需求規(guī)格說明書的輸入?yún)⒖假Y料。功能摘要總結該產(chǎn)品將供給的主要優(yōu)點和特性，而不必涉及每個功能的細節(jié)。對功能加以組織，使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。功能清單及重要程度說明說明：功能名稱、功能描述、重要程度。編號級別重要程度功能名稱功能描述備注重要程度，以編號級別重要程度功能名稱功能描述備注業(yè)務需求目標系統(tǒng)業(yè)務活動〔可選〕業(yè)務需求目標系統(tǒng)業(yè)務活動〔可選〕功能名稱功能與業(yè)務比照關系表說明：業(yè)務組為主編寫業(yè)務需求，業(yè)務需求提交至信息技術組后，由信息技術組建立目標系統(tǒng)業(yè)務模型并與業(yè)務組進展確認〔本操作可選，也可由信息技術組與開發(fā)商合作建立假定和約束說明：列出進展本軟件開發(fā)工作的假定和約束，例如：開發(fā)語言、開發(fā)期限等。格式限制說明：本項將指定由現(xiàn)有的標準或規(guī)章派生的要求。例如：報表格式；數(shù)據(jù)命名；財務處理；審計追蹤，等等。硬件限制說明：本項包括在各種硬件約束下運行的軟件要求，例如，應當包括：硬件配置的特點〔接口數(shù)，指令系統(tǒng)等；內(nèi)存儲器和關心存儲器的容量。運行環(huán)境約束說明：硬件設備、支持軟件、接口、掌握等方面的約束名稱名稱具體要求設計約束【可選】說明：開發(fā)過程中必需使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術、第三方產(chǎn)品等。產(chǎn)品應當遵循的標準或標準說明：闡述本產(chǎn)品應當遵循什么標準、標準或業(yè)務規(guī)章，違反標準、標準或業(yè)務規(guī)章的產(chǎn)品通常不太可能被承受。具體需求功能需求具體功能內(nèi)容說明：對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需求。非功能需求外部接口用戶接口說明：供給用戶使用軟件產(chǎn)品時的接口需求。例如，假設系統(tǒng)的用戶通過顯示終端進展操作，就必需指定如下要求：對屏幕格式的要求說明：對界面上的各對象、類型、寬度、取值范圍、數(shù)據(jù)來源、能否為空等屬性進展描述。報表或菜單的頁面打印格式和內(nèi)容輸入輸出的需求說明：解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等。對軟件的數(shù)據(jù)輸出及必需標明的掌握輸出量進展解釋并舉例，包括對硬拷貝報告〔正常結果輸出、狀態(tài)輸出及特別輸出〕以及圖形或顯示報告的描述。程序功能鍵的可用性說明：快捷鍵定義等。硬件接口【可選】說明：要指出軟件產(chǎn)品和系統(tǒng)硬部件之間每一個接口的規(guī)律特點。還可能包括如下事宜：支撐什么樣的設備，如何支撐這些設備，有何商定。軟件接口【可選】說明：在此要指定需使用的其他軟件產(chǎn)品〔例如，數(shù)據(jù)治理系統(tǒng)、操作系統(tǒng)或數(shù)學軟件包字、助記符、規(guī)格說明號、版本號、來源。對于每一個接口，這局部應說明與軟件產(chǎn)品相關的接口軟件的目的，并依據(jù)信息的內(nèi)容和格式定義接口，但不必具體描述任何已有完整文件的接口，只要引用定義該接口的文件即可。【接口定義】源系統(tǒng)目標系統(tǒng)/客戶化開發(fā)文件類型文件數(shù)量頻度簡單度/人工接口類型

填寫接口完成的任務〔inbound〕還是輸出接口〔outbound〕填寫接口輸入方系統(tǒng)或部件填寫接口輸出方系統(tǒng)或部件填寫文件類型；假設通過數(shù)據(jù)庫表來交互，請指明數(shù)據(jù)庫及表名填寫數(shù)據(jù)處理的頻度填寫接口數(shù)據(jù)的驅(qū)動模式是人工〔manual〕還是自動(automatic)，還是都支持填寫是實時接口還是批量接口等【其他系統(tǒng)具體信息】說明：列出全部與接口交互的外圍系統(tǒng)的具體信息。包括輸入、輸出系統(tǒng)等系統(tǒng)數(shù)據(jù)庫軟件位置

填寫與接口交互的系統(tǒng)名稱填寫是接口的數(shù)據(jù)源系統(tǒng)(source)還是目標系統(tǒng)(object)填寫交互系統(tǒng)使用的數(shù)據(jù)庫及版本填寫交互系統(tǒng)的軟件名稱交互系統(tǒng)的架構類型是B/SC/S。填寫該軟件在交互軟件體系中所出的位置填寫交互系統(tǒng)的開發(fā)商和支持商填寫具體的支持商或技術團隊【接口隸屬系統(tǒng)的具體信息[可選]】系統(tǒng)系統(tǒng)填寫接口隸屬系統(tǒng)的名稱模塊隸屬于具體的模塊名稱數(shù)據(jù)庫隸屬系統(tǒng)的數(shù)據(jù)庫及版本負責人掌握報告【接口配置】接口根底信息配置說明：接口根底信息的配置工程，描述配置的方式。接口運行參數(shù)配置說明：接口運行參數(shù)的配置方式和步驟。【其他配置[可選]】說明：外圍系統(tǒng)或相關模塊的配置。通信接口【可選】說明：指定各種通信接口。例如，局部網(wǎng)絡的協(xié)議等等。其他非功能性需求名稱具體要求名稱具體要求靜態(tài)數(shù)值需求動態(tài)數(shù)值需求精度時間特性要求可用性牢靠性可維護性安全性可移植性可擴展性兼容性可移植性可擴展性兼容性…靜態(tài)數(shù)值需求說明：支持的終端數(shù)；支持并行操作的用戶數(shù)。動態(tài)數(shù)值需求說明：欲處理的事務和任務的數(shù)量，以及在正常狀況下和峰值工作條件下肯定時間周期中處理的數(shù)據(jù)總量。精度說明:對該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。時間特性要求說明：對于該軟件的時間特性要求，如對：a．響應時間；b．更處理時間；c．數(shù)據(jù)的轉換和傳送時間；d．解題時間等要求。數(shù)據(jù)治理要求【可選】說明：需要治理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預見的增長對數(shù)據(jù)及其重量的存儲要求做出估算。可用性指出一般用戶和高級用戶要高效地執(zhí)行特定操作所需的培訓時間，指出典型任務的可評測任務次數(shù)或依據(jù)用戶或?qū)檺鄣钠渌到y(tǒng)確定系統(tǒng)的可用性需求性能牢靠性指出可用時間百分比(xx.xx%)、使用小時數(shù)、維護訪問權、降級模式操作等。平均故障間隔時間(MTBF)。平均修復時間(MTTR)—系統(tǒng)在發(fā)生故障后可以暫停運行的時間。指出系統(tǒng)輸出要求具備的周密度〔區(qū)分率〕和準確度〔依據(jù)某一的標準。文檔需求說明：主要是在線用戶手冊與幫助系統(tǒng)，也包括其他的文檔第三方產(chǎn)品【可選】說明：使用到的第三方產(chǎn)品相關的使用許可、使用限制、接口標準。數(shù)據(jù)字典說明：把相關的數(shù)據(jù)抽取出來統(tǒng)一維護，在其他章節(jié)如有類似信息描述，則關聯(lián)到數(shù)據(jù)字典的相關局部并加關心說明，如：引用到的字段等。補充資料【可選】待確定的問題列表【可選】需求標題1需求標題1調(diào)查方式調(diào)查人調(diào)查對象時間、地點需求信息記錄附件四 需求變更申請記錄號：項 目：工程負責人：申請部門：變更的內(nèi)容及其理由

類 型：變更申請人：申請日期：變更內(nèi)容說明變更的內(nèi)容及變更的理由，假設變更為業(yè)務組提出，則業(yè)務組填寫；假設變更為為信息技術組提出，則信息技術組填寫；

開發(fā)工程變更的系統(tǒng)及 說明變更所涉及的工作產(chǎn)品及其當前版本，版本 假設變更為業(yè)務組提出，則業(yè)務組填寫；假設變更為為信息技術組提出，則信息技術組填寫；對業(yè)務及其接 分析需求變更引起的業(yè)務變更、業(yè)務接口的變更，口的影響 業(yè)務組填寫業(yè)務負責人意見：

同意 不同意簽字： 日期：變更結果變更分析對相關的資源影響分析需求變更對人員、開發(fā)設備和目標設備的影響，僅信息技術組填寫風險分析 僅信息技術組填寫對其他系統(tǒng)或接口分析需求變更引起的系統(tǒng)變更、其他系統(tǒng)或接口的變更，的影響 僅信息技術組填寫對開發(fā)工作量、進估量需求變更對開發(fā)工作量和進度的影響，需說明本次變更工/量度和本錢影響 本錢是否超過本工程總開發(fā)工作/總本錢的1%？僅信息技術組填寫研發(fā)部負責人意見：

研發(fā)部審批意見同意 不同意指定驗證人員：簽字： 日期：處經(jīng)理意見： 同意 不同意 匯報上級上級經(jīng)理意見：

簽字： 日期：同意 不同意簽字： 日期：變更結果變更的系統(tǒng)及版本說明變更后的工作產(chǎn)品簽字： 日期：變更驗證驗證變更結果 完整性 是 否簽字：簽字：日期：正確性是否附加變更是否版本和名稱驗證人意見： 符合要求是不符合要求否附件五 工程打算書文件狀態(tài)：文件狀態(tài)：文件標識：[√]草稿當前版本：[]正式公布作者：[]正在修改完成日期：版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注文檔介紹文檔目的文檔范圍參考文獻提示：列出本文檔的全部參考文獻〔可以是非正式出版物，格式如下：[標識符]作者，文獻名稱，出版單位〔或歸屬單位例如：[AAA]1.5術語與縮寫解釋縮寫、術語縮寫、術語解釋工程介紹工程范圍提示：用簡練的語言說明本工程“是什么說明本工程“應當包含的內(nèi)容”和“不包含的內(nèi)容工程目標客戶與最終用戶介紹提示：請說明本工程的客戶、用戶及其相關責任人是誰，描述最終用戶的特征。約束提示：請說明在工程開發(fā)過程中應當遵循的標準或標準請說明相關工程可能對本工程造成的影響。說明一些假設和依靠。工程過程定義軟件生命周期模型提示：簡要描述、繪制本工程的軟件生命周期模型。工程標準提示：描述工程需遵循的標準，例如：編碼標準。此處可以表現(xiàn)為編碼標準的鏈接。方法與工具提示：說明在過程中將承受的方法與工具。例如承受RationalRose析與設計，承受VisualSourceSafeMicrosoftOffice方法與工具VisualSourceSafe配置治理用途…4里程碑打算序號 里程碑名稱開頭日期 完畢日期工作成果 備注資源打算人力資源打算提示：制定本工程的角色職責表，并為的工程成員安排角色〔一個人可以兼多個角色。角色高層領導工程經(jīng)理需求分析員系統(tǒng)設計員程序員測試員…軟硬件資源打算

職責 人員姓名 工作說明提示：分析工程開發(fā)、測試、運行所需的軟硬件資源和關鍵計算機資源〔會影響軟件產(chǎn)品的性能的CP、內(nèi)存、帶寬等內(nèi)容，主要內(nèi)容包括：資源級別〔〕具體配置獵取方式〔〕與獵取時間使用說明〔如“誰”在“什么”時候使用〕軟硬件資源名稱…文檔交付列表

級別 具體配置 獵取方式與時間 使用說明序號序號交付文檔名稱交付日期備注風險治理打算提示：以下是各個列標題的解釋。商定在工程中的風險治理方案，例如：風險識別頻度、風險跟蹤頻度等。風險級別：確定風險的嚴峻性、可能性、風險系數(shù)風險描述：緩解方案或者應急打算。風險級別風險級別風險編號嚴峻性可能性風險系數(shù)風險描述緩解方案應急打算(1-5)(%)(嚴峻性*可能性)溝通打算甲方代表甲方代表乙方代表溝通方式溝通頻率/時間期望結果附件工程進度打算進度表提示：制定工程開發(fā)的進度表〔建議給出工程里程碑打算例如：編號編號里程碑名稱估量完畢時間備注需求調(diào)研完成實現(xiàn)完成集成測試完成系統(tǒng)測試完成試運行完畢工程驗收附件六 工程打算變更說明工程名稱工程名稱申請日期工程打算變更申請申請變更的輸入名稱，版本，完成日期等信息《工程打算》變更的內(nèi)容及其理由評估量劃變更將對工程造成的影響工程負責人簽字變更申請的審批意見審批意見：處經(jīng)理審批簽字，日期審批意見：研發(fā)部負責人審批簽字，日期審批意見：業(yè)務部門意見簽字，日期更改工程打算變更后的輸入名稱，版本，完成日期等信息《工程打算》工程負責人簽字附件七 設計說明書文件狀態(tài)：文件狀態(tài)：文件標識：[√]草稿當前版本：[]正式公布作者：[]正在修改完成日期：版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注引言編寫目的說明編寫這份具體設計說明書的目的，指出預期的讀者。背景說明：待開發(fā)軟件系統(tǒng)的名稱；本工程的任務提出者、開發(fā)者、用戶和運行該程序系統(tǒng)的計算中心。定義列出本文件中用到特地術語的定義和外文首字母組詞的原詞組。參考資料列出有關的參考資料，如：本工程的經(jīng)核準的打算任務書或合同、上級機關的批文；屬于本工程的其他已發(fā)表的文件；本文件中各處引用到的文件資料，包括所要用到的軟件開發(fā)標準。列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠取得這些文件的來源。程序系統(tǒng)的構造用一系列圖表列出本程序系統(tǒng)內(nèi)的每個程序〔包括每個模塊和子程序〕的名稱、標識1〔標識符〕設計說明從本章開頭，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對一般狀況的。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內(nèi)容往往與它所隸屬的上一層模塊的對應條目的內(nèi)容一樣，在這種狀況下，只要簡潔地說明這一點即可。程序描述給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，并且，還要說明本程序的特點〔如是常駐內(nèi)存還是格外駐？是否子程序？是可重人的還是不行重人的？有無掩蓋要求？是挨次處理還是并發(fā)處理等。功能說明該程序應具有的功能，可承受IPO〔即輸入一處理一輸出圖〕的形式。性能說明對該程序的全部性能要求，包括對精度、敏捷性和時間特性的要求。輸人項給出對每一個輸入項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效范圍、輸入的方式。數(shù)量和頻度、輸入媒體、輸入數(shù)據(jù)的來源和安全保密條件等等。輸出項給出對每一個輸出項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式，數(shù)據(jù)值的有效范圍，輸出的形式、數(shù)量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。算法具體說明本程序所選用的算法，具體的計算公式和計算步驟。流程規(guī)律用圖表〔例如流程圖、判定表等〕輔以必要的說明來表示本程序的規(guī)律流程。接口用圖的形式說明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序，說明參數(shù)賦值和調(diào)用方式，說明與本程序相直接關聯(lián)的數(shù)據(jù)構造〔數(shù)據(jù)庫、數(shù)據(jù)文卷。存儲安排依據(jù)需要，說明本程序的存儲安排。注釋設計說明預備在本程序中安排的注釋，如：加在模塊首部的注釋；加在各分枝點處的注釋；對各變量的功能、范圍、缺省條件等所加的注釋；對使用的規(guī)律所加的注釋等等。限制條件說明本程序運行中所受到的限制條件。測試打算說明對本程序進展單體測試的打算，包括對測試的技術要求、輸入數(shù)據(jù)、預期結果、進度安排、人員職責、設備條件驅(qū)動程序及樁模塊等的規(guī)定。尚未解決的問題說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。2〔標識符〕設計說明F．32N附件八 單元測試用例測試范圍說明：本用例測試的功能點。測試環(huán)境1：硬件環(huán)境：硬件環(huán)境：客戶端：軟件環(huán)境：客戶端：網(wǎng)絡環(huán)境：2：數(shù)據(jù)預備EXCEL測試預備的數(shù)據(jù)。測試編號功能模塊－子模塊－編號測試工程模塊功能－子模塊功能測試編號功能模塊－子模塊－編號測試工程模塊功能－子模塊功能用例描述描述測試上述功能的測試點依靠描述無環(huán)境及初環(huán)境1始數(shù)據(jù)依靠樣例測試本用例依靠的相關用例名稱序號前置條件測試子項執(zhí)行步驟預期結果實際結果備注測試序號 填寫本用說明測試詳細列出對應每一對應每一填寫與測例運行的的根本流各個用例步的推測個執(zhí)行步試相關聯(lián)前置條還是備選角色的操結果；件。如登流；要求作的動陸、權測試遍歷作。限、設備所有的備就緒等； 選流；

驟的實際的核對結果； 點、檢查點。附件九 設計評審報告文件狀態(tài)：[√]草稿[]正式公布[]正在修改

文件標識：ProjectName-當前版本：X.Y作 者：完成日期：Year-Month-Day版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注根本信息提示：由評審主持人或評審員填寫此表格。待評審的工作成果待評審的工作成果工作成果名稱，標識符，版本，作者，時間…技術評審方式〔正式評審〕或者(走查)評審時間評審地點參與技術評審的人員類別名字工作單位職稱、職務：主持人評審記錄員缺陷識別和跟蹤評審問題跟蹤表評審問題跟蹤表編問題問題嚴峻提交提交問題解決措施/問實問備號描述類型性者日期處理緣由說明題際題注負責解關關人決閉閉狀日驗態(tài)期證人123評審結論與意見提示：由主持人或評審員填寫此表格。[[]評審結論[√]工作成果根本合格，需要作少量的修改，之后通過審核即可。[]工作成果不合格，需要作比較大的修改，之后必需重對其評審。意見負責人簽字：簽字日期：附件十 系統(tǒng)/用戶測試打算文件狀態(tài)：文件狀態(tài)：文件標識：[√]草稿當前版本：[]正式公布作者：[]正在修改完成日期：版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注測試范圍與主要內(nèi)容提示：系統(tǒng)測試小組應當依據(jù)工程的特征確定測試范圍與內(nèi)容。一般地，系統(tǒng)測試的主要內(nèi)容包括功能測試、強健性測試、性能測試、用戶界面測試、安全性〔security〕測試、安裝與反安裝測試等。測試方法提示：例如黑盒測試和白盒測試。設備設備配置硬件名稱/類型備注客戶端網(wǎng)絡工具類型類型工具開發(fā)商版本測試治理缺陷跟蹤用于功能性測試的工具用于性能測試的工具測試掩蓋監(jiān)測器或評測器測試掩蓋監(jiān)測器或評測器測試進度打算任務制定測試打算設計測試實施測試執(zhí)行測試測試完成準則提示：

人員 任務 開頭日期 完畢日期對于非嚴格系統(tǒng)可以承受“基于測試用例”的準則：100％；95％時。對于嚴格系統(tǒng)，應當補充“基于BUGnCPUBUGmn10，m1。2個/萬行程序；100%；BUG提示：依據(jù)所承受的BUG1〕BUG〔2〕BUGBUGBUG附錄.本打算審批意見工程經(jīng)理審批意見：工程經(jīng)理審批意見：簽字日期附件十一系統(tǒng)/用戶測試報告根本信息測試依據(jù)測試范圍測試驗收標準測試環(huán)境描述測試驅(qū)動程序描述測試人員測試時間須注明每次回歸測試的時間測試工具實況記錄

例如：參照標準、客戶需求、需求規(guī)格說明書、測試用例等提示：可以把測試驅(qū)動程序當作附件模塊模塊測試用例編號期望結果測試結果缺陷密度是否執(zhí)行了回歸測試測試總評價依據(jù)對測試結果提出一個關于軟件力量的全面分析，需標明遺留的主要缺陷、局限性和軟件的約束限制等，并提出軟件測試過程中程序中的缺乏。依據(jù)測試標準及測試結果，綜合評價軟件的開發(fā)是否已到達預定目標。缺陷修改記錄提示：假設承受了缺陷治理工具，能自動產(chǎn)生缺陷報表的話，則無需本表。缺陷名稱缺陷名稱缺陷類型嚴峻程度模塊緣由駐留時間解決方案…測試人員簽字/日期：附件十二試運行打算文件狀態(tài)：文件標識：ProjectName-TestRun-PLAN[√]草稿當前版本：X.Y[]正式公布[]正在修改作 者：完成日期：Year-Month-Day版本/狀態(tài)版本/狀態(tài)作者參與者起止日期備注試運行目標提示：說明本次試運行的主要內(nèi)容與目標〔必需是可以驗證的。工作條件提示：說明試運行地點、參與人員、軟硬件設施、經(jīng)費等要求。應遞交的工作成果工作成果名稱工作成果名稱估量完成時間試運行報告報錯趨勢分析報告……進度表〔1〕用MicrosoftProject制作進度表GanttChar〕表制作一份進度表。任務名稱及其描述12…可能存在的困難與風險

開頭時間 完畢時間 參與人員提示：指出可能存在的困難和風險，制定應急打算以應對突發(fā)大事。附錄：本打算審批意見工程經(jīng)理或試運行負責人審批意見：簽字日期提示：工程經(jīng)理或者技術負責人依據(jù)工程打算以及現(xiàn)實狀況〔如可以支配的人力資源工程經(jīng)理或試運行負責人審批意見：簽字日期附件十三數(shù)據(jù)遷移打算數(shù)據(jù)遷移的重要大事和里程碑日期數(shù)據(jù)遷移前的備份要求數(shù)據(jù)遷移測試結果清單轉換工作進度表〔1〕用MicrosoftProject制作進度表〔GanttChart〔2〕或者在此處用表格制作一份進度表，例如：任務名稱及其描述12…轉換操作步驟以及問題處理步驟6．數(shù)據(jù)核對打算7．數(shù)據(jù)遷移的需求和實施打算8．應急預案及回退打算分析引發(fā)轉換失敗的潛在緣由

開頭時間 完畢時間 參與人員提示：說明轉換失敗的幾類緣由，考慮人員、軟硬件設施、經(jīng)費等因素。預防措施提示：針對轉換失敗的幾類緣由，制定預防措施。大事處理及回退打算提示：在突發(fā)大事消滅時的應對策略，應從人員組織、流程制定等方面考慮。組織機制提示：建立應急處理小組成員，明確職責到人。應急處理人員應急處理人員角色職責培訓打算說明培訓內(nèi)容，時間，地點，培訓講師等信息。附錄：本打算審批意見工程負責人審批意見：工程負責人審批意見：簽字日期研發(fā)部審批意見簽字日期業(yè)務部門審批意見簽字日