技術(shù)研發(fā)文檔模版0.10
第一部分 總綱 一﹑目 的： 1. 規(guī)范公司內(nèi)部技術(shù)研發(fā)工作的文檔管理； 2. 保持技術(shù)研發(fā)工作的完整性與連續(xù)性； 3. 防止技術(shù)流失，減少風險； 4. 使技術(shù)文檔成為技術(shù)研發(fā)工作中的重要組成部分。 二﹑適用范圍：本公司內(nèi)部一切與技術(shù)研發(fā)有關(guān)的部門及個人，包括 1. 總經(jīng)理； 2. 技術(shù)部門經(jīng)理或負責人； 3. 研發(fā)工程師； 4. 測試工程師； 5. 技術(shù)支持工程師。 三﹑目 標： 通過切實可行的文檔管理規(guī)范，使得研發(fā)工作透明，明確，有章可循，合作無障礙， 銜接環(huán)節(jié)暢通；使得所有的研發(fā)產(chǎn)品從開始研發(fā)——研發(fā)進程——測試——修改——階段性結(jié)束 ——產(chǎn)品轉(zhuǎn)化——升級維護過程中的所有環(huán)節(jié)都得以在相應的文檔中體現(xiàn)。 四﹑版 本：E2003V0.10（簡稱V0.10）。 五﹑制定原則： 1. 實用：鑒于公司目前的狀況，通用性的開發(fā)模板（如國標）在很大程度上對于本公司 并不實用，所以本規(guī)范將不會完全照搬此類模板，而是根據(jù)公司的具體情況制定公 司內(nèi)部的標準； 2. 可行：可行性是該標準的起碼要求，沒有可行性的標準不能成為真正的“標準”； 3. 高效：如果將國標中的所有規(guī)范內(nèi)容都納入本標準，一定可以達到目的，實現(xiàn)目標。 但是，同時必將為相關(guān)人員增添大量的工作量，而且很多工作對于本公司來說是冗 余，從而造成相關(guān)人員的抵觸情緒，使標準難于貫徹。所以，本標準應力求在盡量 少的模板中體現(xiàn)盡量多的內(nèi)容； 4. 科學：本標準的制定雖然不完全照搬其他通用性的標準，但將大量參照通用標準，特 別是國標中的某些部分內(nèi)容，不是拋棄國標，而是以國標為原則，以保證科學性； 5. 建立在廣泛意見基礎上：本標準并非公司某一個人單方面的意愿，而是從公司利益出 發(fā)，全體相關(guān)人員共同參與，集體的結(jié)晶。 六﹑實行過程及生效日期： 1. V0.10版的規(guī)范為規(guī)范草稿，草稿制訂完成后，將在相關(guān)部門和相關(guān)人員中進行傳閱 和廣泛征求意見。經(jīng)過三次全體相關(guān)人員參與討論和修改，由總經(jīng)理審批簽字后的 規(guī)范版本為0.40。 2. V0.40為試用版本，在V0.40的試用過程中，將要求并給予相關(guān)人員以合理的時間盡量 按照V0.40版的要求規(guī)范修改，補充和完善V0.40版以前（包括V0.10以前欠缺的文 檔）的有價值文檔。在此期間，如有新的研發(fā)工作開始啟動，將要求相關(guān)人員按照 V0.40版的規(guī)范要求進行文檔的相關(guān)操作。在此過程中，如果發(fā)現(xiàn)規(guī)范中需要修改 和補充之處，每經(jīng)過一次大幅度的修改，版本即升級到V0.5i（i=1,2,3,…n,），每 經(jīng)過一次小的修改或補充，版本將升級為V0.4j（j=1,2,3,…,n）。 3. V1.00為正式版本。此時的版本已經(jīng)經(jīng)過討論，試用，修改，補充和不斷完善，并且 V1.00以前欠缺的文檔與V0.40試用過程中的文檔都已經(jīng)按照V0.40版本的要求整理 完畢，此時的V0.40版已經(jīng)成熟，可以整體升級到V1.00版。V1.00版本的文檔規(guī)范 將作為公司內(nèi)部與技術(shù)研發(fā)工作相關(guān)的所有人員在今后相當一段時間內(nèi)共同遵守的 規(guī)范，并且將文檔的撰寫工作作為技術(shù)研發(fā)的一個重要組成部分正式納入到技術(shù)研 發(fā)工作中。 4. V1.00規(guī)范將具有強制性和高約束力。 （注：Vi.00，i=0,1,2,…表示i版本系列；Vi.mn，i，m，n=0，1，2，…表示i版本系列下 的改動或升級） 第二部分 目錄索引 一﹑版本控制規(guī)則 二﹑立項 1﹑說明 2﹑模板 三﹑需求分析 1﹑說明 2﹑模板 四﹑可行性分析 1﹑說明 2﹑模板 五﹑功能定義 1﹑說明 2. 模板 六﹑概要設計 1﹑硬件部分 1. 說明 2. 模板 2﹑軟件部分 1. 說明 2. 模板 七﹑詳細設計 1﹑硬件部分 1. 說明 2. 模板 2﹑軟件部分 1. 說明 2. 模板 八﹑測試 1﹑測試流程 2﹑測試要求 1. 硬件部分 2. 軟件部分 3﹑測試模板 1. 硬件部分 2. 軟件部分 九﹑從研發(fā)到產(chǎn)品的過渡 1. 要求 2. 模板 十﹑技術(shù)支持 1. 要求 2. 模板 十一﹑文檔工作的評估與審核 1. 評估標準 2. 審核要點 第三部分 內(nèi)容 一﹑版本控制規(guī)則 1. 版本狀態(tài)：Beta/測試版，Release/正式版，Changing/變更 2. 版本號：版本號以三位數(shù)字表示，格式為i.jk（i=0，1，2，…，n；jk=01，…，9 9） a. Beta版，i=0 b. 第一次正式發(fā)布的Release版，1.00 c. 用Changing來表示Beta或Release版本的修改或升級 d. 小的改動或升級i，j保持不變，只增加k值即可，k的升值幅度為修改或升級處的數(shù) 目，當k值達到或增加至9時，j=j+1，k=0 e. 比較大的改動如，一次修改或升級處的數(shù)目>10，功能性的增加或改變，則i保持不 變，增加j值。如果是功能性的修改或變動，每有一項j+1；如果是>10的非功能 性的修改，每10處修改，j+1，個數(shù)部分用k來表示 f. 重大變動，i值增加 g. 累計功能變動超過百次，i+1，jk=00 二﹑立項 立項管理（Project Initialization Management，PIM）的目的是采納符合公司最大利益的立項建議，通過立項管理使該建議 成為正式的項目（合法化）。杜絕不符合公司最大利益的立項建議被采納，避免公司人 力資源的，資金，時間的浪費。 立項管理是決策行為，目標是“做正確的事情”（do right things）。而立項之后的研發(fā)管理活動是保證項目團隊“正確地做事情”(do things right)?！罢_的決策”+“正確地執(zhí)行”才有可能產(chǎn)生好的產(chǎn)品。 1﹑說明： 1. 立項：任何一次研發(fā)工作的啟動，包括全新的項目和在以往的項目基礎上進行升級或 改版的項目，都需要進行立項的工作。 2. 項目分級：為了明晰立項的工作，使之有條理，可操作，所以將項目區(qū)分為一級項目 和二級項目兩個不同的等級 a﹑一級項目：包括全新的項目的啟動，原有項目的重大改版和升級 b﹑二級項目：在以往項目的基礎上進行的非重大的版本修改和完善 3. 項目審批： a﹑ 所有一級項目必須由項目負責人提交項目申請計劃書，并就項目的相關(guān)情況向總經(jīng) 理和技術(shù)總監(jiān)書面陳述或面對面溝通，得到總經(jīng)理和技術(shù)總監(jiān)的審批簽字后方能 啟動； b﹑ 一級項目必須附加需求分析與可行性分析 c﹑ 二級項目可以由部門經(jīng)理指定或由項目負責人申請得到部門經(jīng)理審批簽字后即可執(zhí) 行，不必交由總經(jīng)理和技術(shù)總監(jiān)審批簽字； d﹑對于二級項目，必須將項目計劃申請書（紙介質(zhì)）交由技術(shù)文檔負責人歸檔，總 經(jīng)理及技術(shù)總監(jiān)對二級項目的進展情況具有知情權(quán)，而項目負責人具有向總經(jīng)理 和技術(shù)總監(jiān)匯報（主動或被動）項目相關(guān)情況的義務； e﹑項目申請計劃書一式兩份：紙介質(zhì)文檔與電子文檔。紙介質(zhì)文檔作為技術(shù)檔案由 專門負責人員備份歸檔。電子文檔按規(guī)范要求存儲在公司指定的文檔服務器上。 4. 權(quán)利，責任與義務 a﹑ 總經(jīng)理，技術(shù)總監(jiān)，部門經(jīng)理對其所具有審批權(quán)限的項目申請計劃書具有否決的權(quán)利； b﹑ 項目申請人有權(quán)要求否決人說明被否決的理由，而且否決人必須在被否決的項目申 請計劃書中陳述否決理由； c﹑ 具有審批權(quán)限的人對于項目的合理性，需求性，可行性等判斷負有全權(quán)責任； 2﹑項目申請計劃書 |項目申請計劃書/立項建議書 | |項目編號 |EPF2003NOX-01 |級 別 |一級項目 □二級項目 | |類 別 |□指定項目 申請項目 |版本說明 |V0.10 | |申 請 人 |Su |申請日期 |2003-8-18 | |負責人 |Su |組 成 員 |Su,Zhang,Yu | |項目名稱 |基于GPRS的圖像傳輸 |產(chǎn)品名稱 |G-BIU（Hardware，GPRS-Based | | | | |Image | | | | |Unit），G-BIUST(Software，G-BI| | | | |U Support Toolkit) | |理由陳述 | |資源配置需求| | | | |成本簡要核算|（暫時可不添此項） | |目 標 |近 期 |中 長 期 |遠 期 | | |（年月日~ 年月日） |（年月日~ 年月日） |（年月日~ 年月日） | | | | | | |問題與解決|問 題 |（在此陳述進行該項目可能遇到和需要解決的問題，除了技術(shù)層面外 | | | |，還包括設備， | | | |人員配備等方方面面的主要問題） | | |解決方法 |針對以上的問題，提出解決建議 | |備注說明 | | |審批結(jié)果 |□通過 □否決 |審批日期 | |審批人簽字| | |審批意見 | | 三﹑需求分析： 如果說立項管理是為了解決do right things和do things right的問題，那么需求分析就是要解決do what things的問題。需求產(chǎn)生目標，目標引領(lǐng)方向。好的需求分析不僅要解決“需要做什么” ，同時明確“什么不需要做”。最好的，可能產(chǎn)生最大利益的產(chǎn)品是“恰如其分”的產(chǎn)品。 所謂“恰如其分”就是：產(chǎn)品的功能恰好滿足那些特定的需求，產(chǎn)品功能不多也不少。一 般的情況下，總結(jié)出“需好做什么”比區(qū)分“什么不需要做”要來的容易，但“什么不需要做 ”的界定往往會影響到成本投入和利益產(chǎn)出的比例。 1﹑說明： 1. 需求分析工作的安排：進行一項產(chǎn)品的開發(fā)工作的一般流程應該是：市場調(diào)查—需求 分析—可行性研究—立項審核—概要設計（總體設計）—詳細設計—單元測試—集成測試 —修改完善—項目評估，審核—批量生產(chǎn)—投放市場—技術(shù)支持與售后服務。 2. 需求的種類：需求的本質(zhì)上都來源于市場，但是在具體表現(xiàn)上又有所不同。有的需求 直接由用戶提出，目標明確；而有些需求則是我們從市場的零星反饋中總結(jié)出來的 ，帶有預見性和自主性。 3. 需求分析的主要目的：從市場的反饋或?qū)κ袌龅挠^察與預見中總結(jié)出市場的需求，并 用理性的思維對這些需求進行分析和總結(jié)，將需求明確，為后面的工作奠定基礎。 4. 需求分析的作用：需求分析是市場與技術(shù)的轉(zhuǎn)換點。經(jīng)過需求分析后，工作的重心即 由市場轉(zhuǎn)移到技術(shù)，明確的需求分析是真正進行研發(fā)工作的起點，是進行產(chǎn)品開發(fā) 一系列后序工作的基礎。 5. 需求在進行研發(fā)的過程中如果發(fā)生變更，需要填寫“需求變更說明書” 2﹑模板1 |需求分析說明書/報告 | |配置編號 |EPF2003NOX-02 |作者 | |提交時間 |2003-8-18| |目標用戶 |陳述產(chǎn)品的目標用戶 | |需求陳述 | |內(nèi)容 |級別 | | |1 | |□A □B □C | | |2 | | | | | | | | |解決方法 |簡單描述針對需求的初步解決意向 | |附加說明 | | |討論意見 | | |項目評審委| | |員會結(jié)論 | | A需求：緊急，重要 B需求：重要，不緊急 C需求：非A,B類需求 模板2 |需求/功能變更 說明書 | |配置編號 |EPF2003NOX-02-01 |歷史版本 |V2.00 |改后版本 |V2.17 | |產(chǎn)品名稱 |G-BIU(GPRS-Based Image |負責人 | |時間 |2003-8-19 | | |Unit) | | | | | |...
技術(shù)研發(fā)文檔模版0.10