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