歐克軟件科技公司產品開發部配置管理制度附配置申請單.pdf
下載文檔
上傳人:職z****i
編號:1317377
2025-03-04
27頁
558.64KB
1、文件編號:GM/KFB/CMS/20090720 版本號:V1.00.000 產品開發部配置管理制度部門:產品開發部編寫:*審核:批準:日期:2009-07-20 *有限公司.;.修 改 歷 史序號版本更改處更改內容更改人/日期1 V1.00.000 創建文件*/2009-07-20 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16.;.目錄第一章概述.51.目的 .52.范圍 .53.術語 .54.角色與職責 .65.VSS 配置庫目錄結構.76.配置項命名規則.77.配置項編號規則.78.配置項狀態變遷規則.109.配置項版本號規則.10第二章配置管理范圍.11第三2、章配置庫建立.11第四章配置管理流程.121.配置管理流程.錯誤!未定義書簽。2.基線建立流程.143.變更控制流程.154.產品發布流程.16第五章配置庫權限變更管理.17第六章配置庫備份.17第七章配置庫使用規范.17第八章附錄.18附錄 1 附錄清單.18附錄 2 配置庫目錄結構.19附錄 3 配置申請單.20.;.附錄 4 受控庫產品清單.21附錄 5 變更申請單.22附錄 6 發布產品配置表.23附錄 7 產品發布申請及驗收表.24附錄 8 產品發布檢查表.26附錄 9 產品發布清單.27.;.第一章概述1.目的為了保證產品開發部研發項目文件的安全性、機密性;為了保證軟件產品的完整性3、有效性及可追溯性,特根據部門實際情況制訂本制度。2.范圍適用于產品開發部所有項目。3.術語概念描述軟件配置管理(Software Configuration Management,SCM)是指通過執行版本控制、變更控制等規程,以及使用合適的配置管理軟件,來保證所有配置項的完整性 和可跟蹤 性。配置管理是對工作成果的一種有效保護。配置項(CI,Configuration Items)產品配置 是指一個產品在其生命周期各個階段所產生的各種形式和各種版本的文檔、計算機程序、部件及數據的集合。該集合中的每一個元素稱為該產品配置中的一個配置項.;.基線(BaseLine)基線 就是一個CI 或一組 C4、I 在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態,而這個過程被稱為“基線化”。每一個基線都是其下一步開發的出發點和參考點。每個基線都將接受配置管理的嚴格控制,對其的修改將嚴格按照變更控制要求的過程進行,在一個軟件開發階段結束時,上一基線加上增加和修改的基線內容形成下一個基線,這就是基線管理 的過程。(基線:是指在軟件開發過程中的里程碑,這些里程碑的標志是一項或多項經過正式的技術評審并一致認同的CI 的提交)4.角色與職責角色職責項目經理確定配置項、確定配置庫目錄權限;審查配置庫變更;項目開發過程中,監督配置庫使用情況;員工離職時,配置庫歸檔完整性審核。開發小組根據配置管理制度5、,進行配置庫的日常使用測試小組從開發庫中取出版本進行整合測試;負責驗證代碼變更及修改是否正確執行。測試小組測試通過的版本方可放入受控庫。配置管理員負責配置庫的建立、權限設置、負責培訓開發人員使用配置管理工具、對配置庫使用情況進行管理和監督、建立配置庫基線;定期備份配置庫;建立和完善配置管理制度。評審小組對項目中的變更進行評審、監控;協調開發小組、測試小組、配置管理員進行配置庫的優化和管理。.;.5.VSS 配置庫目錄結構開發庫:主要用來保存開發過程中不穩定的配置項(源碼和相關文檔),主要由開發人員支配。受控庫:用來保存基線產品(階段性提交的通過評審且相對穩定的配置項),主要由配置管理員支配。發6、布庫:用來保存發布的產品,即交付給用戶的產品、升級包、文檔等,主要由測試人員支配。(這里的用戶特指總工辦,這里的發布屬于公司內部發布。)6.配置項命名規則配置項的命名規則分兩種:1)在開發庫和受控庫中,命名規則為:項目編號_子模塊名稱 _類型名稱類型名稱:為用戶需求說明書、源代碼、可執行文件、測試報告等。例子:CDDT-1_ 地鐵維護單元_源代碼,CDDT-1_ 用戶需求說明書。2)在發布庫中,命名規則為:項目編號_子模塊名稱 _類型名稱 _版本號(日期 _序號)例子 1:CDDT-1_ CDDT-1_地鐵維護單元_源代碼 _V1.00.000例子 2:CDDT-1_受控庫產品清單_200907、714 7.配置項編號規則1)配置項編號規則:固定字段/項目編號 _子模塊編號 /版本號(日期_序號)配置庫(vss_PDMIS)開發庫(1work)受控庫(2confirmed發布庫(3release)存放基線產品存 放 發布產品存 放配 置項.;.示例 1:以下表可行性分析報告為例:QR704/01/KFB/GM2000-MN/V1.00.000 示例 2:以下表質量月報為例:QR701/01/KFB/GM2000-MN/200907 2)表 1 說明紅色部分為公司內/外審時,必須提交的文檔。其余為部門內部文檔。編號第二字段為01-50,表示是公司內/外審必須文檔,51 以后的數字代表部門8、內部文檔。改表預留了號碼,以后可以根據實際需要添加刪除文檔。階段文檔類型文檔編號備注定義需求調研計劃QR704/51/KFB 需求調研記錄QR704/52/KFB 可行性分析報告QR704/01/KFB 用戶需求說明書QR704/02/KFB 軟件/系統需求規格說明書QR704/53/KFB 需求確認表QR704/54/KFB 項目計劃(包含附件:進度Project 文檔)QR704/03/KFB 配置管理計劃QR706/01/KFB 質量保證計劃QR701/51/KFB 設計概要設計說明書QR704/04/KFB 詳細設計說明書QR704/55/KFB 實現測試測試計劃QR704/05/KF9、B.;.階段文檔類型文檔編號備注測試報告QR704/06/KFB 未關閉缺陷原因說明表QR704/56/KFB發布硬件/軟件設計更改說明QR704/07/KFB改造項目需提交項目總結報告QR704/08/KFB 用戶手冊QR704/09/KFB 日常支持文檔配置管理類:配置管理報告QR706/02/KFB 配置申請單QR706/51/KFB 變更申請單QR706/52/KFB 受控庫產品清單QR706/53/KFB 配置狀態報告QR706/54/KFB 產品發布申請及驗收表QR706/03/KFB 發布產品配置表QR706/04/KFB 日常支持文檔質量保障類:質量保證報告QR701/51/K10、FB 質量保證檢查表QR701/52/KFB 質量月報QR701/01/KFB 代碼檢查表QR701/53/KFB 日常支持文檔管理評審類:評審通知QR704/10/KFB 預讀記錄QR704/57/KFB 評審意見匯總表QR704/11/KFB.;.階段文檔類型文檔編號備注評審問題跟蹤表QR704/58/KFB 評審會議紀要QR704/59/KFB 設計開發任務書QR704/60/KFB 工作任務單QR704/12/KFB 8.配置項狀態變遷規則1)配置項的狀態有三種:“草稿”(Draft)、“正式發布”(Released)和“正在修改”(Changing)。2).配置項狀態變遷如下圖所示。11、配置項剛建立時其狀態為“草稿”。配置項通過評審(或審批)后,其狀態變為“正式發布”。當配置項的狀態成為“正式發布”時任何人都不能隨意修改,必須依據“申請審批執行變更再評審結束”的“變更控制流程“執行。當配置項修改完畢并重新通過評審(或審批)時,其狀態又變為“正式發布”,如此循環。9.配置項版本號規則配置項的版本號與配置項的狀態緊密相關:(1)處于“草稿”狀態的配置項的版本號格式為:V 0.00.Z“V“Version 的首字母,代表后面的數字為版本號。Z 數字范圍為001-999 隨著草稿的不斷完善,“Z”的取值應遞增。“Z”的初值為001,增幅為001.變更控制正式發布正在修改自由修改草稿評12、審或審批否決通過.;.例子:V 0.00.001(2)處于“正式發布”狀態的配置項的版本號格式為:V X.Y.000 X 為主版本號,取值范圍為1-9。Y 為次版本號,取值范圍為00-99。配置項第一次“正式發布”時,版本號為V 1.00.000。如果配置項的版本升級幅度比較小,一般只增大Y 值,X 值保持不變。只有當配置項版本升級幅度比較大時,才允許增大X 值。例子:V 1.01.000(3)處于“正在修改”狀態的配置項的版本號格式為:V X.Y.Z Z 數字范圍為001-999 配置項正在修改時,一般只增大Z 值,X.Y 值保持不變。當配置項修改完畢,狀態重新成為“正式發布”時,將Z 值設13、置為0,增加 X.Y 值。參見規則(2)。例子:V 1.01.001 第二章配置管理范圍配置管理包括:所有研發項目文檔、源代碼、可執行程序,特殊工具及相關資料等。項目文檔主要指:立項建議書、項目計劃、需求說明書、軟件規格說明書、概要/詳細設計說明書、數據庫表結構、測試文檔、用戶使用說明書以及項目過程中管理類文檔等。特殊工具及其相關資料指開發或測試過程中比較特殊的工具,以及其使用文檔等,如覺得有必要也納入配置庫的管理。第三章配置庫建立1.項目立項時,由項目經理申請建立項目配置庫,配置管理員與項目經理確定配置項,并參考附錄 2:配置庫目錄結構,建立配置庫以及配置庫目錄結構;項目經理提供配置庫權限清14、單(內容應包括員工姓名、項目名稱、目錄權限等),由配置管理員為相關人員的設置配置權限。2.配置庫權限設置完成之后,由配置管理員將配置庫名稱、訪問路徑、訪問權限等信息以郵件方式通知各相關人員;配置庫使用人員以各自的用戶名和密碼進行訪問配置庫。.;.3.配置庫密碼只能在服務器上設置,但使用人員可以在客戶端修改自己的秘密,如配置庫使用人員密碼遺忘,可以與配置管理員取得聯系,進行修改密碼。第四章配置管理流程.;.1.配置管理流程定義階段項目經理 編寫項目計劃并通過評審。配置管理員 依據 項目計劃 編寫配置管理計劃項 目 經 理 審 批 配 置 管 理 計劃項目經理 依據配置管理計劃在規定時間申請建立 15、定義基線.申請建立基線的流程見基線建立流程項目經理 依據配置管理計劃在規定時間申請建立定義基線.設計階段實現階段項目經理 依據配置管理計劃在規定時間申請建立實現基線測試階段項目經理 依據配置管理計劃在規定時間申請建立測試基線發布階段項目經理 依據配置管理計劃在規定時間申請建立發布基線.項 目 經 理 依 照產品發布流程,發布產品。產品發布流程見 產品發布流程開 發 人 員 按照 配 置 管 理相關規則(見本 制 度 第 六章)在開發庫中 創 建、命名、標記、變更(按照變更控制流程)配置項。配置管理員按照配置管理計劃 和本制度管理配置庫的變更、備份、基線建立、等工作。項目經理和 評審小組 負責變16、更、基線建立等工作的審批和對配置管理工作的檢查、指導、監督工作。測試人員負責測試和產品的發布等工作。整個階段變更控制流程見變更控制流程.;.2.基線建立流程項目經理 按照配置管理計劃在規定時間填寫配置申請單,申請建立相應的基線。評審小組對所申請建立的基線進行審批?通過項目經理 將配置申請單(紙質和電子版)送交 配置管理員,配置管理員依照配置申請單建立基線 并填寫 受控庫產品清單。流程結束未通過評審組長 將 配置申請單送還 項目經理,并向其說明原因。配 置 申 請單見附錄3 受控庫產品清單見附錄 4.;.3.變更控制流程配置項或基線需要變更時,申請人 填寫變更申請單評審小組 對所申請 變 更 進17、 行 審批?通過執行人 進行相應的變更操作.評審組長 將 變更申請單送還 申請人,并向其說明原因。未通過評審小組 對變更后配置項再進行審批?通過申請人 將變更申請單(紙質和電子版)送交 配置管理員,配置管理員獲取變更后的版本的配置項到受控庫 并填寫 受控庫產品清單。未通過變更申請單見附錄 5 流程結束.;.4.產品發布流程項目經理 填寫 發布產品配置表(僅第一次發布時填寫)和產品發布申請及驗收表項目經理 送交相關人員對發布產品進行 審批?通過項目經理 將 發布產品配置表 和產品發布申請及驗收表(紙質和電子版)送交 配置管理員配置管理員 依照 發布產品配置表 和產品發布申請及驗收表 將發布產品打18、包,放入發布庫,同時填寫 產品發布檢查表和產品發布清單,并辦理和總工辦的發布產品交接手續。未通過部門經理 將發布產品配置表 產品發布申請及驗收表.送還 項目經理,并向其說明原因。流程結束 發 布 產 品 配 置表 見附錄 6 產品發布申請及驗收表 見附錄 7 產 品 發 布 檢 查表 見附錄 8產品發布清單見附錄 9.;.第五章配置庫權限變更管理若在使用配置庫的過程中需要變更配置庫管理權限,可以由項目管理員或項目經理以郵件或口頭方式通知配置管理員,配置管理員變更之后,將變更結果以電子郵件方式通知受影響的人員、項目經理、項目管理員及其相關人員。配置管理員根據配置庫權限變更頻率,決定每隔一段時間將19、配置庫權限清單與各項目經理進行審核確認,各項目經理審核后,若有權限需要進行變更,應及時通知配置管理員。第六章配置庫備份配置管理員應定期做好配置庫的備份,以防意外引起的服務器上資料的丟失,避免給公司帶來嚴重的損失。具體實施規范如下:1.配置管理員自創建項目配置庫起,每月15 號、28 號對配置庫進行硬盤備份一次(完全備份),為了節約硬盤空間,只保留最近的兩次備份文件,之前的備份文件將被刪除。2.配置管理員每遇到有基線產生時,對基線單獨硬盤備份一次。3.當項目結項時,對該項目成果進行硬盤和光盤雙重備份,備份后的光盤標記上備份日期并附上內容清單,移交部門行政秘書保管。4.如遇特殊情況需要特殊備份時,20、需項目經理和部門經理協商后,通知配置管理員做特殊備份。第七章配置庫使用規范1.所有立項的項目,都必須申請建立配置庫。開發過程中所有文檔和代碼必須納入配置庫管理,若因未納入配置庫管理造成的資料丟失或版本差異,其責任皆由開發人員及項目經理承擔。2.配置庫服務器密碼只有配置管理員和產品開發部經理掌握,其他人如因特殊原因需要該密碼,必須經過產品開發部經理的批準后方能獲取;并在使用完密碼之后,通知產品開發部經理和配置管理員,配置管理員及時設置新的密碼,以保證服務器資料的安全性和機密性。3.各配置庫的使用人員必須使用各自的用戶名和密碼進入配置庫,訪問授權的配置庫。各使用人員不得將自己的用戶名和密碼泄漏給其21、他人員,若因泄露密碼而引起的后果將由泄漏密碼者本人承擔。.;.4.各項目的配置庫用于項目組正式開發使用,項目組成員不得惡意對其進行修改、刪除、增加等操作;若因對 VSS 工具不熟悉,需要學習,可以向配置管理員提出需求,由配置管理員為其提供可以練習的配置庫。5.各項目經理負責定期檢查配置庫的使用情況,查看是否有員工進行無故刪除或惡意修改文件的行為;并對開發人員提交的文檔和代碼的及時性、準確性和完整性進行檢查。6.在研發人員離職時,由其項目經理負責檢查配置庫,檢查該人員提交的代碼或文檔是否完全放入配置庫管理,確認版本和相應文件完整無誤后,項目經理在“員工離職申請單”中簽字,該員工方可離職。同時項目22、經理應及時通知配置管理員,取消該人員的所有權限。若因項目經理審核不細致造成的代碼或文檔移交不完整,或項目經理未及時通知配置管理員取消權限,而造成的損失,該責任完全由項目經理承擔。7.在配置庫使用時,為了避免配置庫checkin 或 checkout 時引起沖突,需注意:項目經理在劃分模塊時注意每個人的模塊之間盡量不要重疊。開發人員在修改文件之前,養成事先checkout 的習慣。開發人員注意checkin 的頻率,盡量及時checkin,最好每天提交一次。第八章附錄附錄 1 附錄清單序號名稱存儲路徑附件 2 配置庫目錄結構Vss_Assets/3.軟件開發/1.開發過程/6.配置管理附件 3 23、配置申請單附件 4 受控庫產品清單附件 5 變更申請單附件 6 發布產品配置表附件 7 產品發布申請及驗收表Vss_Assets/3.軟件開發/1.開發過程/5.發布附件 8 產品發布檢查表附件 9 產品發布清單.;.附錄 2 配置庫目錄結構配置庫目錄結構每一個項目的配置庫可分為1work(開發庫)、2confirmed(受控庫)和3release(發布庫),如下為配置庫目錄結構模板,可以根據實際情況增減:一級目錄二級目錄三級目錄四級目錄說明Vss_項目編號1work 1doc(文檔目錄)1project項目啟動、定義階段產生的相關文檔(如:項目計劃、配置管理計劃等)2management與該24、項目相關的管理文檔(如:質量月報、配置狀態報告等)3requirement需求階段產生的文檔(用戶需求說明書,軟件規格說明書等)4design項目設計階段產生的相關文檔(如:概要設計文檔、詳細設計文檔等)5test項目測試階段產生的文檔(如:測試報告、測試大綱等)6review評審文檔7meeting會議文檔8workreport每周工作報告(項目周報、工作日志等)9training培訓文檔2src(源碼目錄)1code項目代碼(可以根據項目需求自定義子目錄)2html系統原型3install安裝包3temp(項目臨時文件)用于存放項目開發工程中產生的臨時文件2confirmed配置管理員可根25、據配置管理計劃建立基線目錄3release發布庫.;.附錄 3 配置申請單配置申請單說明:1.該表格適用于配置項提交、基線建立申請。2.配置項或基線入受控庫時填寫該表。編號:QR706/51/FKB/項目編號/日期(格式:20090717)申請部分(由申請人填寫)項目名稱成都地鐵一號線項目編號申請類型 配置項提交 基線建立申請人申請日期2009-05-19 配置項所屬基線配置項名稱編號版本號存儲路徑(開發庫)提交時間備注2009-05-19 申請說明評審部分(由評審組長填寫)評審時間評審組長評審組成員審批結果 批準 拒絕評審組長簽字:日期:.;.附錄 4 受控庫產品清單受控庫產品清單序號項目名26、稱(編號)入庫類型所屬基線配置項名稱存放位置(受控庫)版本號存放位置(開發庫)入庫時間申請人活動依據備注004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019.;.附錄 5 變更申請單變更申請單填表說明:1.該表適用于配置項變更和基線變更時填寫。2.評審組長一般為項目經理。編號:QR706/52/FKB/項目編號/日期(格式:20080717)項目名稱項目編號申請類型配置項變更基線變更申請人申請日期1.變更申請(由變更申請人填寫)申請變更的配置項所屬基線配置項名稱編號版本號配置項對應開發庫路徑V1.00.000 變更的內容27、及其理由估計配置項變更將對項目造成的影響變更申請人簽字2.審批變更申請(由評審組長填寫)審批結果審批結果 批準 拒絕評審組長簽字:日期:批準變更的配置項變更執行人時間限制備注3.變更配置項(由變更執行人填寫)變更后的配置項名稱變更后的版本號變更完成日期備注2009-05-23 4.結束變更(由評審組長填寫)重新審批結果重新審批結果 批準 拒絕評審組長簽字:日期:.;.附錄 6 發布產品配置表說明:1.此表由項目經理填寫。2.此表中的模塊必須填寫完整,所列模塊必須是組成該項目的所有模塊。3.項目名稱(項目編號):編號:QR706/04/KFB/項目編號/發布版本號序號模塊名稱數據庫名稱及版本數據28、庫文件名稱操作系統名稱及版本開發工具及版本配置/安裝文件有無可執行文件支持軟件模塊負責人備注1 調度員工作站Sybase 12.5 Windows 2000 professional VC+6.0 MFC 見配置文件OGW-Config.xml 分析員工作站Sybase 12.5 Windows 2000 professional VC+6.0 MFC 見配置文件/conf/systemconfig.xml 3 通信前置機Sybase 12.5 Windows 2000 professional VC+6.0 MFC 見配置文件SCADACONFIG.xml 4 服務器后臺Sybase 12.29、5 Solaris 10.0GCC 3.4.6 無5 Web 復視Sybase 12.5 Windows 2003 Advanced Server Visual Studio.Net 2005(C#)DSN:scada UID:sa PWD:sqlsql 6 維護員工作站SQL Server2000 Windows 2000 professional VC+6.0 MFC 請查看:使用注意問題.txt提交人(簽字,包含日期):接收人(簽字,包含日期):.;.附錄 7 產品發布申請及驗收表產品發布申請及驗收表填表說明:1.產品在發布前,必須填寫本表。本表所有需要簽名的欄目必須手簽。2.經過測試的30、產品發布,由測試人員填寫本表的主要欄目。通過了系統測試、升級包測試的,發布類型判定為“定版發布”。通過或部分通過緊急發布測試的,部分通過系統測試、升級包測試的,都只能判定為“讓步發布”。3.未經過測試的產品發布,由項目經理或指定的開發人員填寫本表。發布類型只能是“特例發布”。表單編號:QR706/03/KFB/項目編號/日期(格式:20090717)1.申請部分(除特別說明外均由申請人填寫)產品名稱項目名稱 _子模塊名稱 發布日期2009-07-07 發布版本號V1.00.000 產品形態完整產品模塊產品升級包其它 _ 發布類型定版發布讓步發布特例發布其它 _ 適用用戶(版本)洛張線申請人附件31、名稱發布包名稱項目名稱 _ 子模塊名稱_版本號.rar發布包存儲路徑VSS_GM2000-MN/3release/洛張線/洛張線 _LZ_V1.00.000 發布包文件清單序號文檔/模塊名稱編號對應開發庫存儲路徑備注1 項目編號 _子模塊名稱 _類型名稱_版本號(日期 _序號)VSS_GM2000-MN/1work/2src/1code/洛張項目基礎版本:石懷線調度員工作站,未修改。2 CDDT-1_地鐵維護單元 _源代碼_V1.00.000無VSS_GM2000-MN/1work/2src/1code/洛張項目基礎版本:石懷線分析員工作站,未修改。3 CDDT-1_項目計劃 _V1.00.032、00 QR704/03/KFB/CDDT-1/V1.00.000VSS_GM2000-MN/1work/2src/1code/洛張項目4 CDDT-1_地鐵維護單元 _可執行文件 _V1.00.000無VSS_GM2000-MN/1work/2src/1code/洛張項目5 VSS_GM2000-MN/1work/2src/1code/洛張項目6 VSS_GM2000-MN/1work/2src/1code/洛張項目7 VSS_GM2000-MN/1work/1doc/4design/洛張項目8/VSS_GM2000-MN/1work/2src/3install/洛張項目9/VSS_GM20033、0-MN/1work/2src/3install/洛張項目.;.發布產品簡介及安裝說明1.產品簡介本產品對洛張線所管轄的牽引變電所、分區所、開閉所以及接觸網開關等牽引供電設施進行實時數據采集和集中監控管理。本產品包括WEB 復視系統、調度員工作站、分析員工作站、后臺、通訊前置機、維護員工作站6 個模塊。本版本是該軟件的初始版本。基礎版本:石懷線GM2000 系統新增/修改功能序號新增/修改功能修改后對應發布包文件名對應 BugFree 缺陷號備注1 2 2.審批部分(由相關負責人填寫)最終審批結果:同意發布 拒絕發布部門經理簽字:簽字日期:職位同意發布拒絕發布簽字(必需手寫)簽字日期備注測試人34、員項目經理配置管理員3.驗收部分(由總工辦及質量管理辦公室填寫)接收產品拒絕接收產品拒絕理由驗收時間驗收人簽字備注負責人確認簽字:簽字日期:.;.附錄 8 產品發布檢查表產品發布檢查表編號產品發布檢查表編號檢查目標項目編號(產品編號)_版本號檢查人配置管理員(手簽)檢查日期檢查項序號檢查項(產品發布申請及驗收表)檢查項狀態檢查記錄備注1 產品名稱填寫是否正確(若為子模塊產品,名稱是否和發布產品配置表所列一致)?通過2 產品形態選擇是否正確?3 發布類型選擇是否正確?4 附件名稱填寫是否正確?5 發布包名稱填寫是否符合規范?6 發布包存儲路徑填寫是否正確?7 發布包清單所列文件名稱是否正確?8 35、發布產品是否有幫助菜單項?9 發布包清單所列版本號是否和產品幫助-關于菜單所示版本號一致(若為文檔,文件版本號是否和內部所示版本號一致)?10 發布清單對應開發庫存儲路徑是否正確?11 發布清單對應開發庫標簽號是否正確?12 新增/修改功能對應發布包的文件名是否正確?13 新增/修改功能對應BugFree 缺陷號是否正確?14 發布產品是否含有源碼的可執行文件?15 發布產品是否含有產品配置表?16 發布產品是否含有用戶使用說明書?17 發布產品配置表是否涵蓋了產品運行必須的組件?填表說明:1.本表由配置管理員進行填寫,需根據產品發布檢查項進行檢查,并填寫檢查結果。也可作為項目經理、部門經理、QA檢查產品發布工作的依據。2.進行 QA 檢查時,可以用以下字符替代“檢查項狀態”的文字說明。通過:Y 不通過:X 部分通過:P 待定:TBD(To Be Defined).;.附錄 9 產品發布清單序號項目名稱(編號)發布包名稱產品形態發布包存儲路徑申請人申請日期活動依據備注001 002 003 004 005 006 007 008 009 010