1、第一部分 總綱一目 的：（1） 規范公司內部技術研發工作的文檔管理；（2） 保持技術研發工作的完整性與連續性；（3） 防止技術流失，減少風險；（4） 使技術文檔成為技術研發工作中的重要組成部分。二適用范圍：本公司內部一切與技術研發有關的部門及個人，包括（1） 總經理；（2） 技術部門經理或負責人；（3） 研發工程師；（4） 測試工程師；（5） 技術支持工程師。三目 標：通過切實可行的文檔管理規范，使得研發工作透明，明確，有章可循，合作無障礙，銜接環節暢通；使得所有的研發產品從開始研發研發進程測試修改階段性結束產品轉化升級維護過程中的所有環節都得以在相應的文檔中體現。四版 本：E2003V0.1

2、0（簡稱V0.10）。五制定原則：（1） 實用：鑒于公司目前的狀況，通用性的開發模板（如國標）在很大程度上對于本公司并不實用，所以本規范將不會完全照搬此類模板，而是根據公司的具體情況制定公司內部的標準；（2） 可行：可行性是該標準的起碼要求，沒有可行性的標準不能成為真正的“標準”；（3） 高效：如果將國標中的所有規范內容都納入本標準，一定可以達到目的，實現目標。但是，同時必將為相關人員增添大量的工作量，而且很多工作對于本公司來說是冗余，從而造成相關人員的抵觸情緒，使標準難于貫徹。所以，本標準應力求在盡量少的模板中體現盡量多的內容；（4） 科學：本標準的制定雖然不完全照搬其他通用性的標準，但將大

3、量參照通用標準，特別是國標中的某些部分內容，不是拋棄國標，而是以國標為原則，以保證科學性；（5） 建立在廣泛意見基礎上：本標準并非公司某一個人單方面的意愿，而是從公司利益出發，全體相關人員共同參與，集體的結晶。六實行過程及生效日期：（1） V0.10版的規范為規范草稿，草稿制訂完成后，將在相關部門和相關人員中進行傳閱和廣泛征求意見。經過三次全體相關人員參與討論和修改，由總經理審批簽字后的規范版本為0.40。（2） V0.40為試用版本，在V0.40的試用過程中，將要求并給予相關人員以合理的時間盡量按照V0.40版的要求規范修改，補充和完善V0.40版以前（包括V0.10以前欠缺的文檔）的有價值

4、文檔。在此期間，如有新的研發工作開始啟動，將要求相關人員按照V0.40版的規范要求進行文檔的相關操作。在此過程中，如果發現規范中需要修改和補充之處，每經過一次大幅度的修改，版本即升級到V0.5i（i=1,2,3,n,），每經過一次小的修改或補充，版本將升級為V0.4j（j=1,2,3,n）。（3） V1.00為正式版本。此時的版本已經經過討論，試用，修改，補充和不斷完善，并且V1.00以前欠缺的文檔與V0.40試用過程中的文檔都已經按照V0.40版本的要求整理完畢，此時的V0.40版已經成熟，可以整體升級到V1.00版。V1.00版本的文檔規范將作為公司內部與技術研發工作相關的所有人員在今后相

5、當一段時間內共同遵守的規范，并且將文檔的撰寫工作作為技術研發的一個重要組成部分正式納入到技術研發工作中。（4） V1.00規范將具有強制性和高約束力。（注：Vi.00，i=0,1,2,表示i版本系列；Vi.mn，i，m，n=0，1，2，表示i版本系列下的改動或升級）第二部分 目錄索引一版本控制規則二立項1說明2模板三需求分析1說明2模板四可行性分析1說明2模板五功能定義1說明2. 模板六概要設計1硬件部分（1） 說明（2） 模板2軟件部分（1） 說明（2） 模板七詳細設計1硬件部分（1） 說明（2） 模板2軟件部分（1） 說明（2） 模板八測試1測試流程2測試要求（1） 硬件部分（2） 軟件部

6、分3測試模板（1） 硬件部分（2） 軟件部分九從研發到產品的過渡（1） 要求（2） 模板十技術支持（1） 要求（2） 模板十一文檔工作的評估與審核（1） 評估標準（2） 審核要點第三部分 內容一版本控制規則（1） 版本狀態：Beta/測試版，Release/正式版，Changing/變更（2） 版本號：版本號以三位數字表示，格式為i.jk（i=0，1，2，n；jk=01，99）a. Beta版，i=0b. 第一次正式發布的Release版，1.00c. 用Changing來表示Beta或Release版本的修改或升級d. 小的改動或升級i，j保持不變，只增加k值即可，k的升值幅度為修改或升級處

7、的數目，當k值達到或增加至9時，j=j+1，k=0e. 比較大的改動如，一次修改或升級處的數目>10，功能性的增加或改變，則i保持不變，增加j值。如果是功能性的修改或變動，每有一項j+1；如果是>10的非功能性的修改，每10處修改，j+1，個數部分用k來表示f. 重大變動，i值增加g. 累計功能變動超過百次，i+1，jk=00二立項立項管理（Project Initialization Management，PIM）的目的是采納符合公司最大利益的立項建議，通過立項管理使該建議成為正式的項目（合法化）。杜絕不符合公司最大利益的立項建議被采納，避免公司人力資源的，資金，時間的浪費。立項

8、管理是決策行為，目標是“做正確的事情”（do right things）。而立項之后的研發管理活動是保證項目團隊“正確地做事情”(do things right)。“正確的決策”+“正確地執行”才有可能產生好的產品。1說明：（1） 立項：任何一次研發工作的啟動，包括全新的項目和在以往的項目基礎上進行升級或改版的項目，都需要進行立項的工作。（2） 項目分級：為了明晰立項的工作，使之有條理，可操作，所以將項目區分為一級項目和二級項目兩個不同的等級a一級項目：包括全新的項目的啟動，原有項目的重大改版和升級b二級項目：在以往項目的基礎上進行的非重大的版本修改和完善（3） 項目審批：a 所有一級項目必須

9、由項目負責人提交項目申請計劃書，并就項目的相關情況向總經理和技術總監書面陳述或面對面溝通，得到總經理和技術總監的審批簽字后方能啟動；b 一級項目必須附加需求分析與可行性分析c 二級項目可以由部門經理指定或由項目負責人申請得到部門經理審批簽字后即可執行，不必交由總經理和技術總監審批簽字；d對于二級項目，必須將項目計劃申請書（紙介質）交由技術文檔負責人歸檔，總經理及技術總監對二級項目的進展情況具有知情權，而項目負責人具有向總經理和技術總監匯報（主動或被動）項目相關情況的義務；e項目申請計劃書一式兩份：紙介質文檔與電子文檔。紙介質文檔作為技術檔案由專門負責人員備份歸檔。電子文檔按規范要求存儲在公司指

10、定的文檔服務器上。（4） 權利，責任與義務a 總經理，技術總監，部門經理對其所具有審批權限的項目申請計劃書具有否決的權利；b 項目申請人有權要求否決人說明被否決的理由，而且否決人必須在被否決的項目申請計劃書中陳述否決理由；c 具有審批權限的人對于項目的合理性，需求性，可行性等判斷負有全權責任；2項目申請計劃書項目申請計劃書/立項建議書項目編號EPF2003NOX-01級 別一級項目 二級項目 類 別指定項目 申請項目版本說明V0.10申 請 人Su申請日期2003-8-18負責人Su組 成 員Su,Zhang,Yu項目名稱基于GPRS的圖像傳輸產品名稱G-BIU（Hardware，GPRS-B

11、ased Image Unit），G-BIUST(Software，G-BIU Support Toolkit)理由陳述資源配置需求成本簡要核算（暫時可不添此項）目 標近 期（年月日 年月日）中 長 期（年月日 年月日）遠 期（年月日 年月日）問題與解決問 題（在此陳述進行該項目可能遇到和需要解決的問題，除了技術層面外，還包括設備，人員配備等方方面面的主要問題）解決方法針對以上的問題，提出解決建議備注說明審批結果通過 否決審批日期審批人簽字審批意見三需求分析：如果說立項管理是為了解決do right things和do things right的問題，那么需求分析就是要解決do what th

12、ings的問題。需求產生目標，目標引領方向。好的需求分析不僅要解決“需要做什么”，同時明確“什么不需要做”。最好的，可能產生最大利益的產品是“恰如其分”的產品。所謂“恰如其分”就是：產品的功能恰好滿足那些特定的需求，產品功能不多也不少。一般的情況下，總結出“需好做什么”比區分“什么不需要做”要來的容易，但“什么不需要做”的界定往往會影響到成本投入和利益產出的比例。1說明：（1） 需求分析工作的安排：進行一項產品的開發工作的一般流程應該是：市場調查需求分析可行性研究立項審核概要設計（總體設計）詳細設計單元測試集成測試修改完善項目評估，審核批量生產投放市場技術支持與售后服務。（2） 需求的種類：需

13、求的本質上都來源于市場，但是在具體表現上又有所不同。有的需求直接由用戶提出，目標明確；而有些需求則是我們從市場的零星反饋中總結出來的，帶有預見性和自主性。（3） 需求分析的主要目的：從市場的反饋或對市場的觀察與預見中總結出市場的需求，并用理性的思維對這些需求進行分析和總結，將需求明確，為后面的工作奠定基礎。（4） 需求分析的作用：需求分析是市場與技術的轉換點。經過需求分析后，工作的重心即由市場轉移到技術，明確的需求分析是真正進行研發工作的起點，是進行產品開發一系列后序工作的基礎。（5） 需求在進行研發的過程中如果發生變更，需要填寫“需求變更說明書”2模板1需求分析說明書/報告配置編號EPF20

14、03NOX-02作者提交時間2003-8-18目標用戶陳述產品的目標用戶需求陳述內容級別1A B C2解決方法簡單描述針對需求的初步解決意向附加說明討論意見項目評審委員會結論A需求：緊急，重要B需求：重要，不緊急C需求：非A,B類需求模板2需求/功能變更 說明書配置編號EPF2003NOX-02-01歷史版本V2.00改后版本V2.17產品名稱G-BIU(GPRS-Based Image Unit)負責人時間2003-8-19變更項變更內容變更屬性變更原因是否允許1A D M是 否23附加說明變更屬性中A代表增加，D代表刪除，M代表修改項目評審委員會結論項目評審委員會給出是否進行變更的意見，由

15、評委會主席簽字生效四技術可行性分析 可行性分析是進行研發工作的重要環節，詳細周到的可行性分析與論證為即將啟動的項目把握一道至關重要的關口。技術可行性分析要求從技術層面上分析論證項目的可行性，即能否“做得到，做得快，做得好”。可行性分析報告由項目申請責任人總結，撰寫，并提交到項目評審委員會審閱。有項目申請/建議書，需求定義和需求報告仍然不能進行實質性的開發，必須要進行可行性分析，可行性分析包括幾個部分（1） 市場分析：a. 分析總結市場的發展趨勢，說明產品處于市場的什么發展階段，粗略估計產品的生命周期b. 本產品和同類產品的價格比對c. 統計產品當前市場總額，競爭對手所占的份額，分析本產品有哪些

16、比較優勢，可能占有多少市場份額d. 為產品定位，即確定產品用戶群，分析產品消費群體特征，消費方式及影像市場的因素分析（2） 政策分析a. 分析有無相關政策“支持”或“限制”b. 分析有無地方政府或其他機構的“扶持”或“干擾”（3） 競爭分析a. 分析競爭對手的市場狀況，產品的優點與缺點b. 預測可能形成的競爭的特點與周期（4） 技術可行性分析（5） 時間和資源可行性分析a. 按正常的運作，從產品開發到投入市場，時間上是否來得及b. 計劃中的人員能否及時到位c. 計劃中的軟硬件需求能否及時到位d. 成本核算能否負擔得起（6） 知識產權分析a. 是否已經存在某些專利將妨礙本產品的開發與推廣b. 產

17、品能否得到知識產權的保護技術可行性分析報告配置編號EPF2003NOX-03報告撰寫人提交時間2003-8-19可行性論述由項目負責人總結，撰寫主要從能否“做得到”，“做得快”，“做得好”的角度分析如果能“做得到”，“做得快”，“做得好”，需要給出通過怎樣的方法保證如果不能，需要給出理由討論意見由技術秘書總結撰寫人提交報告后到項目評審委員會后，項目評審委員組織人員對報告的“可行性論述”展開討論，技術秘書總結各方意見，記述在此欄項目評審委員會意見項目評審委員會給出整體意見，供決策人參考五功能定義1. 說明：功能定義是對do what things的明確界定，是針對明確的需求來定義產品功能的過程。

18、是產品設計的實質性階段，此后的研發工作將圍繞功能定義展開，功能定義說明書是參與研發的人員進行工作的基礎文檔，是產品測試與評審，用戶手冊的編制，市場宣傳的主要依據。2. 模版功能定義說明書配置編號EPF2003NOX-04負責人提交時間2003-8-19功能項功能描述123附加說明項目評審委員會意見項目評審委員會給出整體意見，供決策人參考六概要設計1、硬件部分：為了簡化操作流程，使文檔既能體現設計原理與設計思路，又具有良好的操作性，所以對于硬件部分的概要設計要求只要求給出原理圖，思路描述，主要器件，主要器件的技術參數。概要設計報告（H）配置編號EPF2003NOX-05-H負責人時間2003-8

19、-19原理圖在此添入原理圖配置編號，原理圖配置編號由技術文檔秘書統一編制，編號編制方法待討論，（改動：EPF2003NOX-05-H-01）設計思路描述基本要求：負責人必須對關鍵的設計思想進行清楚的描述主要器件及技術參數器件名稱用途技術參數參考123主要參考資料資料名稱來源編號12l 按照 重要，關鍵性器件>主要器件>輔助性器件的順序描述主要器件及技術參數欄。l 每一種參考資料都有自己的編號如：EPF2003NOX-05-H-R12、軟件部分:軟件部分的概要設計需要提交的報告有：概要設計報告，界面設計報告，數據庫設計報告概要設計報告（S）配置編號EPF2003NOX-05-S-01

20、作者提交時間2003-8-19當前版本V1.20歷史版本V1.00，V1.07，V1.17術語與縮寫解釋術語解釋G-BIAS即GPS-Based Integrated Application System設計約束系統應當遵循的標準或規范軟硬件環境（包括運行環境與開發環境）的約束接口/協議的約束用戶界面的約束*軟件質量約束，包括正確性，健壯性，可靠性，效率（性能），易用性，清晰性，安全性，可擴展性，兼容性，可移植性。（如果有約束，逐一填寫；如果不存在約束，可不填）設計策略擴展策略為了方便擴展，現在采取的措施復用策略說明本系統在當前以及將來的復用策略折衷策略如果存在兩個主要目標難以同時優化時如何折

21、衷系統總體結構描述開發環境配置軟件硬件網絡主要開發工具及語言運行環境要求軟件包括操作系統，第三方軟件平臺硬件網絡數據庫參考資料資料配置編號來源12其他說明如果系統比較復雜，首先將系統分解成若干子系統，對各個子系統繪制邏輯圖，說明子系統的功能*解釋如何以及為什么如此分解系統說明子系統間如何如何協調工作，以實現元系統的功能如果子系統N仍然需要分解成模塊，則（1） 繪制模塊邏輯圖（2） 陳述分解理由（3） 說明模塊間如何協調工作，從而實現子系統的功能如果系統相對簡單，給出用工具Visio繪制的系統邏輯結構圖界面設計報告界面設計報告（S）配置編號EPF2003NOX-05-S-02作者時間2003-8

22、-19當前版本V1.20歷史版本V1.00，v1.07，v1.17界面結構及風格繪制界面視圖（1） 主界面：需要給出界面元素的作用與操作（2） 子界面：給出子界面的主要作用第三方界面元素控件，組件，函數庫及其來源名稱來源作用12數據庫設計報告主要完成數據庫的物理設計，即表的結構設計與對表結構的第三范式處理數據庫設計報告（S）配置編號EPF2003NOX-05-S-03作者時間2003-8-19當前版本V1.20歷史版本V1.00，v1.07，v1.17表匯總表名功能描述1A2B3CA列名數據類型（經度范圍）約束條件備注12補充說明角色與權限可以訪問的表與列訪問權限角色A角色B七詳細設計1. 硬

23、件部分，硬件部分的詳細設計主要體現在下位機軟件的代碼上，所以詳細設計文檔的內容集中在對代碼的要求上面，代碼要求（1） 所有的代碼模塊必須用文件的方式組織（2） 在每一個文件中的開頭以注釋的方式寫如下內容：Copyright（c）2003，*公司，硬件開發部*All rights reserved*文件名稱：*文件標識：文件標識可以統一規定，也可以自己選擇*摘 要：簡要描述該文件的內容*當前版本：*作 者：輸入作者或修改者的名字*完成日期：*取代版本：*原作者 ：*完成日期：（3） 如果用C語言開發a. 必須將.H文件與.C文件區分開來，在.H中定義全局變量，結構，聯合，自定義群體等，如鏈表；函

24、數的聲明b. 在定義函數體前，以注釋方式寫如下內容*函數的主要作用*輸入輸出參數的含義（4） 全局變量的定義要集中，并說明用途（5） 主要變量必須在定義之后說明用途（6） 所有函數的定義必須給出函數的作用詳細設計報告（H）配置編號EPF2003NOX-06-H作者時間2003-8-20當前版本歷史版本所有函數定義列表函數定義主要用途外部接口12流程圖外部接口/庫接口/庫名主要用途來源12通訊協議內部通訊協議外部協議1填入內部通訊協議文檔配置編號如SMPP，S7等2其他說明2.軟件部分軟件部分的詳細設計報告內容相對較多，所以設計報告分成若干部分詳細設計報告（SP1）配置編號EPF2003NOX-

25、06-S-01作者時間2003-8-20當前版本歷史版本系統架構如果能用圖表示，必須用圖表示，不好用圖表示的部分，可以用文字描述主要控件/組件名稱作用來源使用12類/結構類名作用12主要的數據結構數據結構描述12關鍵算法算法作用實現過程12自定義消息消息名稱消息IDInvoke條件12其他說明 主要控件一欄包括：l 第三方控件，如MapX，FlatStyle等，在使用此類控件中必須給出此控件的作用，來源如購買，Share等；必須簡要描述此類控件的使用方法，如果控件本身帶有資料描述，必須以附錄資料的形式給出資料l 主要的類/結構：程序中所有用到的類，包括自己獨立封裝的類，從固有的類中集成下來的類

26、，簡要陳述類的作用。如果回使用建模工具，則需要用類圖來描述出類的結構，繼承關系等。l 主要的數據結構，如結構（記錄），鏈表，棧，隊列，圖，樹及作用l 關鍵算法：關鍵不是復雜，任何一個程序都有關鍵算法，這里的“關鍵”的引申含義為：主要，重要。必須給出算法的作用與實現的思路過程描述詳細設計報告（SP2）配置編號EPF2003NOX-06-S-02作者時間2003-8-20當前版本歷史版本外部接口接口作用參數描述1Map.Distance()23內部接口（方法/函數/過程）接口作用宿主參數描述123其他說明l 所謂接口，不過是函數在特定概念下的稱謂。外部接口，程序中所使用的外部函數。例如，在使用Ma

27、pX控件時，需要使用Map.Distance()接口函數來計算距離，那么既需要描述出Map.Distance()的作用與參數描述l 內部接口：所謂宿主，即指包括此接口的自定義或從固有類繼承而來的類，如果是全局函數，宿主欄填寫G詳細設計報告（SP3）配置編號EPF2003NOX-06-S-03作者時間2003-8-20當前版本歷史版本流程圖配置編號1EPF2003NOX-06-S-03-CF-012其他說明l 流程圖主要描述程序的關鍵流程，對關鍵的判斷依據是：如果沒有此流程圖描述，則對他人理解此程序存有障礙l 由于流程圖一般占用較大空間，所以將其作為詳細設計報告（SP3）的附件八測試 測試是產品

28、研發中相當重要的部分，在IT領域越來越受到人們的普遍重視。高水平的測試不僅可以發現表面存在的bug，還可以發現產品內部設計缺陷，消除潛在隱患，提出修改完善建議等。測試，在產品研發中所占用的時間比例大約是整個研發周期的1/41/3。 但是，鑒于公司的實際情況，需要制定有效的，符合公司使用要求，實用的測試規程。 產品測試規定為兩個部分（1） 內部測試：即指開發人員自己進行的測試工作，基本要求是在一般情況下，產品能夠正常啟動運行即可（2） 產品測試：當內部測試完成以后，測試人員進行產品測試，測試的依據為項目建議書，概要設計報告，功能定義報告，詳細設計報告（3） 集成測試：及產品的各個功能部分一起運作

29、下的測試 產品測試在目前看來，最主要的是要測試產品的功能，測試功能的主要依據則是功能定義報告。在產品測試前，開發人員必須提供一套測試樣本。產品測試報告（HP1）配置編號EPF2003NOX-07-H-01測試人負責人測試時間2003-8-21產品名稱版本歷史版本測試環境及工具測試項功能是否通過備注1Yes No2遺留問題問題描述問題級別原因分析1R Y O2測試結論測試人簽字手寫問題級別：（1） R:即Red，紅色級別，重大問題，關鍵問題，如執行某項功能時，導致系統死機（死循環），崩潰等（2） Y:即Yellow，黃色級別，功能性問題，某項功能無法通過（3） O:即Orange，橙色級別，功能可以實現，但操作十分不便產品測試報告（HP2）配置編號EPF2003NOX-07-H-02測試人負責人測