源代碼管理規(guī)范

1、代碼管理制度1 總則22 源代碼完整性保障23 源代碼的授權(quán)訪問24 代碼版本管理35 源代碼復制和傳播46 系統(tǒng)測試驗收流程56.1 系統(tǒng)初驗56.2 試運行56.3 系統(tǒng)終驗56.4 系統(tǒng)驗收標準66.5 文檔評審通過標準76.6 確認測試通過標準76.7 系統(tǒng)試運行通過標準71總則1、為保障公司源代碼和開發(fā)文檔安全不至于泄露，保證源代碼的完整，明確源代碼控制管理流程，特制定此管理辦法。2、本辦法適用于所有涉及接觸源代碼的各部門各崗位。所涉及部門都必須嚴格執(zhí)行本管理辦法。3、源代碼直接控制管理部門為技術(shù)開發(fā)部。4、本辦法管理重點在于控制管理源代碼的完整性，不被非授權(quán)獲取，不被非授權(quán)復制和傳

2、播。5、本辦法所指源代碼不僅限于公司開發(fā)人員自行編寫實現(xiàn)功能的程序代碼，而且還包括相應的開發(fā)設計文檔及用于支撐整個系統(tǒng)運行所必須具備的第三方軟件、控件和其它支撐庫等文件。2 源代碼完整性保障1、所有軟件的源代碼文件及相應的開發(fā)設計文檔均必須及時加入到指定的源代碼服務器中的指定庫中。2、我們研發(fā)的產(chǎn)品軟件運行所必須的第三方軟件、控件和其它支撐庫等文件也必須及時加入源代碼服務器中指定的庫中。3、軟件開始編寫或者調(diào)整代碼之前，其相應的設計文檔和代碼必須先從相應的SVN庫進行SVNUpdate操作。軟件編碼或功能調(diào)整結(jié)束測試正確無誤后，相應的源代碼必須進行SVNCommi臊作，在最終進行SVNComm

3、i腺作之前需要再進行SVNUpdate操作，查看是否有沖突產(chǎn)生，如果有沖突產(chǎn)生需要和沖突相關(guān)人一并解決沖突。3 源代碼的授權(quán)訪問1、源代碼服務器對于共享的SVN庫的訪問建立操作系統(tǒng)級的，基于身份和口令的訪問授權(quán)。第十條在SVN庫中設置用戶，并為不同用戶分配不同的，適合工作的最小訪問權(quán)限。要求連接SVN庫時必須校驗SVN中用戶身份及其口令。在SVN庫中要求區(qū)別對待不同用戶的可訪問權(quán)、可讀權(quán)、可寫權(quán)。2、曾經(jīng)涉及、觸及源代碼的計算機在轉(zhuǎn)作它用，或者離開研發(fā)部門之前必須由網(wǎng)絡管理人員全面清除計算機硬盤中存儲的源代碼。如果不能確定，必須對計算機中所有硬盤進行全面格式化后方可以轉(zhuǎn)做它用或離開研發(fā)部門。4

4、 代碼版本管理1、終端軟件的版本標識管理終端軟件版本由終端型號、版本號和內(nèi)部修訂號來進行標識。終端型號：終端型號是硬件標識號，也唯一的標識了我們的項目。版本號：由“主版本號.次版本號.修訂號”三段組成，中間是點號分開。版本號的目的主要是管理終端軟件的對外發(fā)布，終端軟件的BUG的記錄和統(tǒng)計，主要是針對于版本號的，測試部、項目部、客戶等會記錄某個版本號的終端軟件存在哪些BUG,BUG會在哪個版本號中得到修正；終端軟件一個新的版本號出來后，我們會統(tǒng)計新的版本號解決了上一個版本號中的哪些BUG,以及增加了哪些新功能，等等。內(nèi)部修訂號：也就是“應用程序的源代碼的svn修訂號”，主要是由軟件部和測試部內(nèi)部

5、來使用，內(nèi)部修訂號唯一標識我們的終端軟件，即：通過內(nèi)部修訂號能夠唯一的找出我們發(fā)布的終端軟件所對應的全部軟件源代碼，目的是為了軟件排錯使用。另外，終端軟件在發(fā)布時，還會給出發(fā)布日期，以便開發(fā)、測試、項目、客戶等相關(guān)人口分”員參考。2、終端軟件版本發(fā)布管理終端軟件主要是以版本號為基準，對外發(fā)布，目前采用不定時發(fā)布策略，發(fā)布的時間由軟件部、項目部和客戶方根據(jù)情況，共同商量決定。由于目前項目時間緊，終端軟件無法得到完整的測試就要發(fā)布，在發(fā)布之后，有一些需要緊急需要修復的BUG，軟件部需要緊急修復后就要發(fā)布更新包，以便用戶能夠使用，所以，在一個版本號發(fā)布后，需要進行多次修訂，對于這些修訂的版本，其版本

6、號保持不變，內(nèi)部修訂發(fā)生變化。軟件BUG記錄、管理和統(tǒng)計軟件BUG的記錄、管理和統(tǒng)計主要以版本號為基準，但為了軟件開發(fā)人員能夠找到BUG的出處，需要用戶、測試人員在報告和驗證BUG時，輸入內(nèi)部修訂號。3、軟件配置組對版本的記錄軟件版本記錄的目標有兩個：記錄軟件版本的發(fā)布歷史；發(fā)布的每一個版本，都要能夠唯一的從源代碼庫（SVN）中找到對應的全部源代碼。測試方案：作為軟件開發(fā)的重要環(huán)節(jié)，作為交付成功的優(yōu)質(zhì)的產(chǎn)品的重要保證手段和方法，軟件測試越來越受到項目的重視。要做好測試首先要做好測試的組織、管理、計設、實施等工作。系統(tǒng)測試方案概述：測試是指在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼的最

7、終復審，是軟件質(zhì)量保證的關(guān)鍵步驟。測試的目標：以較少的用例、時間和人力找出軟件中潛在的各種錯誤和缺陷，以確保系統(tǒng)的質(zhì)量。在實際項目中，測試作為軟件開發(fā)生命周期中的一個重要過程，但從其具體工作的前后過程來看，它又是由一系列的不同測試所組成，這些測試的步驟分為：單元測試、集成測試（又稱組裝測試）、確認測試和系統(tǒng)測試。軟件開發(fā)的過程是自頂向下的，測試則正好相反，以上這些過程就是自底向上，逐步集成的。在項目過程中，我們按以上的測試步驟完成系統(tǒng)的測試。5源代碼復制和傳播1、源代碼向研發(fā)部門以外復制必須獲得總經(jīng)理的書面授權(quán)。并必需記錄復制人、批準人、復制時間、復制目的、文件流向、文件版本或內(nèi)容。2、源代碼

8、以任何介質(zhì)形式進行存儲的備份，必須由專人負責保管。對于這些介質(zhì)地借閱，用于研發(fā)部內(nèi)部使用的必須獲得研發(fā)部經(jīng)理的授權(quán)，對于用于研發(fā)部以外使用的必須獲得總經(jīng)理的書面授權(quán)。3、源代碼的借閱、復制必須進行詳細的登記，必需記錄借閱人、批準人、借閱時間、借閱目的、文件流向、文件版本或內(nèi)容、歸還時間。4、任何紙質(zhì)材料的借閱都必需記錄借閱人、批準人、借閱時間、借閱目的、文件流向、文件版本或內(nèi)容、歸還時間。5、對于因合作需要，需要向外復制、傳播、分發(fā)源代碼的，不論是全部還是部分代碼和資料，均必需和對方簽訂技術(shù)、源碼的保密協(xié)定，明確對方應當承擔的對源碼保密的責任和義務。6系統(tǒng)測試驗收流程嚴格執(zhí)行代碼管理流程。對于

9、開發(fā)完成的系統(tǒng)進行測試發(fā)布。測試發(fā)布流程如下：6.1 系統(tǒng)初驗系統(tǒng)初驗由技術(shù)開發(fā)部進行單項測試，系統(tǒng)進行聯(lián)調(diào)測試無誤后，由開發(fā)部編制項目測試報告，提交測試報告給匯測試部審核，完成系統(tǒng)初驗。6.2 試運行本系統(tǒng)集成后上線運行三個月為試運行期。由公司技術(shù)人員現(xiàn)場排除系統(tǒng)試運行過程中出現(xiàn)的硬件故障及軟件故障，對于易出現(xiàn)問題的設備提供備用件。技術(shù)人員隨時解答業(yè)務人員在使用過程中出現(xiàn)的問題并進行解決。6.3 系統(tǒng)終驗正式驗收主要圍繞設備的配置、功能、性能及各項技術(shù)參數(shù)指標進行，完成用戶整體的系統(tǒng)驗收。當整個系統(tǒng)進入試運行期，技術(shù)開發(fā)部提供行之有效的技術(shù)支持以確保整個業(yè)務的穩(wěn)定和有效地運營，并確保整個業(yè)務

10、能夠順利通過系統(tǒng)驗收。在此同時，技術(shù)開發(fā)部將通過具體的技術(shù)支持幫助匯運維操作人員熟悉和掌握這些設備和維護技術(shù)。系統(tǒng)試運行期是一個非常重要的時期。在此期間，由于運維技術(shù)人員的技術(shù)水平、設備管理、設備操作和具體設備維護之間的磨合，將會出現(xiàn)許多意想不到的問題和人為故障。因此在系統(tǒng)試運行期，技術(shù)開發(fā)人員需配合運維人員提出的要求提供必要的現(xiàn)場技術(shù)支持，同時通過定期維護以避免設備故障的發(fā)生。在通過系統(tǒng)試運行的情況下，技術(shù)開發(fā)的項目小組將和業(yè)務運營人員以及運維人員進行系統(tǒng)終驗。系統(tǒng)調(diào)試、驗收程序：驗收采取過程中定期抽檢、全檢，最后實行總體驗收的方法進行。程序為報告申請驗收，各有關(guān)單位會同驗收，最后會簽認同。

11、參見下圖：系統(tǒng)驗收將由驗收小組進行，驗收時做好記錄，簽署驗收證書，并立檔、歸檔。當驗收不合格時，技術(shù)人員需無條件進行返修。系統(tǒng)的安裝驗收主要有以下內(nèi)容：(1)系統(tǒng)設備器材清單明細以及隨設備包裝的各種附件、資料等是否齊全；(2)各主要設備器材的外觀評估與內(nèi)在技術(shù)指標確認；(3)系統(tǒng)安裝整體外觀效果評估；(3)各系統(tǒng)工程各相關(guān)技術(shù)文件、現(xiàn)場檢查驗收記錄等是否齊全；(4)系統(tǒng)的安裝客觀測試；(5)系統(tǒng)的工程安裝驗收將按用戶需求進行。6.4 系統(tǒng)驗收標準項目的驗收工作包括兩個方面的活動：文檔評審和軟件產(chǎn)品包的測試與試運行檢驗，對于不同的驗收活動制定不同的驗收通過標準。衡量被評審文檔或被測試軟件產(chǎn)品質(zhì)量

12、的一個重要指標是：評審或測試發(fā)現(xiàn)的缺陷數(shù)。為進一步明確文檔或軟件產(chǎn)品的質(zhì)量水平，需要對發(fā)現(xiàn)的缺陷按其嚴重程度進行分類，在本項目中，將對缺陷分為四個等級，如下表所示：嚴重等級分類的解釋嚴重的缺陷對進度的影響可能是非常致命的，或者可能是一個停止器一一即終止用戶繼續(xù)使用系統(tǒng)主要的相同類型的缺陷在很多程序或模塊中出現(xiàn)，需要改正每一個缺陷。例如，在任一程序中沒有遵守編程標準。或者，缺陷終止了用戶按正常方式繼續(xù)前進，但可以繞行次要的這個缺陷是獨立的缺陷，或者不影響用戶繼續(xù)前進，但會帶來不便普通的缺陷并不影響軟件產(chǎn)品的性能，例如，美觀問題和消息中的語法錯誤等6.5 文檔評審通過標準按照評審對象的規(guī)模（頁數(shù)）

13、，根據(jù)評審投入的工作量和發(fā)現(xiàn)的缺陷數(shù)來確定是否通過評審：評審投入的工作量（評審準備和評審會議的時間）：是否在一個合理的范圍內(nèi)，如果投入的評審時間過低，則不論發(fā)現(xiàn)的缺陷數(shù)如何，都不能通過評審。發(fā)現(xiàn)的陷數(shù)：是否在一個合理的范圍內(nèi)，如果發(fā)現(xiàn)的缺陷數(shù)太多，則不能通過評審。如果發(fā)現(xiàn)的缺陷數(shù)低于合理的水平，則需要分析評審過程和評審人員，以便確定是否通過評審。6.6 確認測試通過標準對軟件產(chǎn)品包的確認測試，根據(jù)測試用例質(zhì)量、執(zhí)行測試用例情況和發(fā)現(xiàn)的缺陷數(shù)來確定是否通過確認測試：測試用例質(zhì)量：是否通過評審，如果測試用例沒有通過評審，則不能進入確認測試過程。測試用例的執(zhí)行：確認測試過程必須保證執(zhí)行了所有的確認測試用例數(shù)據(jù)，測試結(jié)果得到真實記錄。發(fā)現(xiàn)的陷數(shù)：與以前階段成果評審、軟件產(chǎn)品的集成測試和系統(tǒng)測試所發(fā)現(xiàn)的缺陷數(shù)相比，是否在一個合理的范圍內(nèi)。一般而言，確認測試階段發(fā)現(xiàn)的缺陷數(shù)應與確認