1、文件編號std-zs-kf-2010-000 中山森中山森創創信息技信息技術術有限公司有限公司 版本/修改a/0 文件名稱文件名稱軟件開發流程和相關規范頁數共 101 頁 中山森創信息技術有限公司中山森創信息技術有限公司 軟件開發流程和相關規范軟件開發流程和相關規范 版權所有，未經雙方許可不得復制或對外傳閱版權所有，未經雙方許可不得復制或對外傳閱 目目 錄錄 1軟件配置管理規范軟件配置管理規范.7 1.1.配置管理目標.7 1.2.配置管理的主要內容.7 1.3.配置管理角色、職責及權限.8 1.3.1.配置經理.8 1.3.2.項目負責人.8 1.3.3.配置管理員（cmo）.9 1.3.4

2、.開發人員.9 1.3.5.軟件測試人員.9 1.3.6.軟件維護人員.10 1.3.7.質量保證人員.10 1.3.8.角色、權限圖.10 1.4.配置管理過程.12 1.5.配置管理工具及環境.13 1.5.1.文件服務器.13 1.5.2.配置管理工具.13 1.5.3.配置服務器.13 1.6.配置管理計劃.14 1.6.1.配置工具的選擇.14 1.6.2.配置庫的基本目錄結構.14 1.6.3.權限設置.15 1.6.4.配置項標識規定.15 1.6.5.協作開發規定.15 1.6.6.其它.15 1.7.配置項管理.15 1.7.1.配置項標識號命名規范.16 1.7.2.配置項

3、名稱命名規范.17 1.7.3.程序文件、數據文件.18 1.8.基線建立及變更管理.18 1.9.文檔版本管理.19 1.9.1.文檔版本及版本號的概念.19 1.9.2.版本號的定義及生成方法.20 1.9.3.定版的具體操作方法.21 1.9.4.定版的具體操作方法.21 1.10.軟件版本管理.21 1.10.1.定版的具體操作方法.21 1.10.2.版本號的定義及生成方法.22 1.10.3.定版的具體操作方法.23 1.10.4.在 vss 上定版的具體操作方法.23 1.10.5.版本發布流程.24 1.10.6.版本保存.25 1.11.公用程序庫的建立及維護.25 1.12

4、.配置庫的安全管理.25 1.12.1.版本保存.25 1.12.2.配置服務器的安全控制.26 1.12.3.配置庫備份.26 1.12.4.配置管理平臺維護.26 1.13.工作空間管理.26 1.14.變更文件的審批與確認.27 2軟件質量保證規范軟件質量保證規范.28 2.1概述.28 2.1.1目標.28 2.1.2方針.28 2.1.3核心內容.28 2.2質量保證活動組織與職責.29 2.2.1質量保證組織結構圖.29 2.2.2角色與職責.29 2.3工作規程.33 2.3.1工作流程圖.33 2.3.2指定質量保證人員及參與項目策劃確認.34 2.3.3早期活動及建立質量保證

5、計劃.34 2.3.4項目計劃的評審.34 2.3.5質量保證計劃的分步實施及報告.34 2.3.6質量保證計劃的維護.35 2.3.7質量保證總結報告.36 2.4質量保證計劃.36 2.4.1質量目標.36 2.4.2質量保證活動要點.36 2.4.3質量保證報告制度.38 3軟件開發過程規范軟件開發過程規范.39 3.1引言.39 3.2軟件開發過程.39 3.3需求開發過程.39 3.3.1目的.39 3.3.2前提.39 3.3.3主要活動.39 3.3.4流程規范.40 3.1.1需求定義流程規范.42 3.1.2需求分析內容.42 3.4總體設計過程.43 3.4.1目的.43

6、3.4.2前提.43 3.4.3主要活動.43 3.4.4流程規范.44 3.5概要設計過程.45 3.5.1目的.45 3.5.2前提.45 3.5.3主要活動.45 3.5.4流程規范.46 3.6詳細設計過程.49 3.6.1目的.49 3.6.2前提.50 3.6.3主要活動.50 3.6.4流程規范.50 3.7系統實現過程.51 3.7.1目的.51 3.7.2前提.51 3.7.3主要活動.51 3.7.4流程規范.52 3.8軟件測試過程.52 3.9系統運行過程.53 3.9.1目的.53 3.9.2前提.53 3.9.3主要活動.53 3.9.4流程規范.54 3.10軟件

7、維護過程.54 4 4軟件測試過程規范軟件測試過程規范.54 4.1軟件測試目的.54 4.2軟件測試過程.55 4.3軟件測試過程與軟件開發過程關系.57 4.4測試計劃.57 4.4.1軟件測試計劃.57 4.4.2測試需求.58 4.5測試設計.58 4.5.1單元測試方案.58 4.5.2集成測試方案.58 4.5.3系統測試方案.59 4.5.4測試工具設計.59 4.6測試實現.59 4.6.1測試用例編制.59 4.6.2測試工具實現.59 4.7測試執行.59 4.7.1單元測試.59 4.7.2集成測試.60 4.7.3系統測試.60 4.7.4用戶測試.60 4.8測試結束

8、.60 5 5設計和開發評審指南設計和開發評審指南.61 5.1目的.61 5.2范圍.61 5.3角色和職責.61 5.3.1主審人.61 5.3.2評審專家.62 5.3.3質量保證人員.62 5.3.4記錄員.62 5.3.5顧客和用戶代表.62 5.3.6相關領導和部門管理人員.62 5.4評審時機.62 5.5評審的基本要求.62 5.6評審依據.63 5.7評審內容.63 5.8評審方式.63 會簽評審.63 會議評審.63 5.9工作程序.64 5.9.1成立評審組.64 5.9.2提供資料.64 5.9.3評委發表意見.64 5.9.4形成評

9、審結論.65 5.9.5評審資料的歸檔.65 5.9.6跟蹤管理.65 6 6編碼規范編碼規范.66 6.1編制目的.66 6.2c#編碼標準.66 6.2.1一般命名規范.66 6.2.2ado.net 命名規范 .67 6.2.3winform control 命名規范.67 6.2.4webcontrol 命名規范.68 6.2.5命名約定.69 6.2.6注釋.69 6.2.7代碼編寫格式.70 6.2.8c#細節規范.73 7 7unixunix 開發環境規范開發環境規范.74 7.1源程序版本管理.74 7.2開發用戶環境設置.75 7.3項目目錄結構.75 7.4軟件測試：.76

10、 8 8軟件單元測試工作指南軟件單元測試工作指南.76 8.1目的.76 8.2單元測試工作內容及其流程.76 8.3單元測試需求獲取.77 8.4單元測試測試策略.77 8.5單元測試工作機制.77 9 9軟件集成測試工作指南軟件集成測試工作指南.78 9.1目的.78 9.2集成測試工作內容及其流程.78 9.3集成測試需求獲取.79 9.4集成測試測試策略.79 9.5集成測試工作機制.79 1010軟件系統測試工作指南軟件系統測試工作指南.79 10.1目的.80 10.2系統測試工作內容及其流程.80 10.3系統測試需求獲取.80 10.3.1功能性測試需求.81 10.3.2性能

11、測試需求.81 10.3.3其它測試需求.81 10.4系統測試策略.82 10.4.1系統測試類型和目標.82 10.4.2采用的測試技術.82 10.5系統測試的工作機制.82 1111軟件開發文檔編制規范軟件開發文檔編制規范.83 11.1引言.83 11.2使用說明.83 11.3常用工具格式規范.84 11.4總體設計說明書編制規范.84 11.5需求規格說明書編制規范.85 11.6概要設計說明書編制規范.86 11.7數據庫設計說明書編制規范.86 11.8軟件維護手冊編制規范.87 11.9用戶手冊編制規范.88 11.10附件.89 1212軟件開發部門職責篇軟件開發部門職責

12、篇.89 12.1軟件部門職責.89 12.1.1售前咨詢.89 12.1.2項目規劃.89 12.1.3需求分析.90 12.1.4軟件原型.90 12.1.5軟件開發.91 12.1.6軟件測試.91 12.1.7軟件實施.91 12.1.8總結驗收.92 12.1.9產品升級.93 12.1.10知識管理.93 12.1.11內部培訓.93 12.1.12開發流程標準化.93 12.2崗位職責.93 12.2.1技術總監.93 12.2.2項目經理.93 12.2.3系統分析員.94 12.2.4高級程序員.94 12.2.5程序員.94 12.2.6測試工程師.94 12.2.7軟件實

13、施人員.95 附錄附錄.95 word 開發文檔格式模板開發文檔格式模板.95 rose模板規范目錄結構模板規范目錄結構.99 軟件開發文檔清單軟件開發文檔清單.100 1軟件配置管理規范軟件配置管理規范 1.1.配置管理目標配置管理目標 通過實施配置管理活動，令項目開發團隊工作在一個規范的配置管理平臺上，從而提高 軟件產品質量、提高軟件開發的整體工作效率，達到用戶滿意。同時，通過配置管理活動， 將項目開發過程中所有的產出、開發活動、管理活動等進行記錄，以方便今后的軟件維護及 類似項目的參照。 1.2.配置管理的主要內容配置管理的主要內容 軟件開發的配置管理主要包括以下內容： 配置項標識的管理

14、； 配置庫的建立及變更管理； 版本控制； 配置管理計劃編制； 公用程序庫的建立及維護； 配置庫的安全管理； 小組協作管理； 工作空間管理； 1.3.配置管理角色、職責及權限配置管理角色、職責及權限 在配置管理平臺下，軟件開發人員按照不同的角色的要求、根據系統賦予的權限來執行 相應的動作。具體主要涉及下列的角色和分工： .3.1.配置經理配置經理 負責指導和控制部門配置管理的各項具體活動的進行，為項目經理的決策提供建議。配 置經理由指定的專人兼任，其具體職責為以下幾項： 建立、管理部門配置管理平臺； 建立項目配置庫； 配置庫的備份等安全管理； 制定配置管理規范； 輔助項目組建立配置

15、管理環境； 審核配置管理計劃； 指導項目組配置管理活動； 監督、考核各項目組配置管理活動的執行情況。 .3.2.項目負責人項目負責人 項目負責人根據配置管理員的建議，批準、監督該項目配置管理的各項活動并控制它們 的進程。其具體職責為以下幾項： 參與規劃、制定和修改項目配置管理策略； 批準、發布配置管理計劃； 決定項目起始基線和開發里程碑； 建立基線，審核基線變更申請； 制定配置管理相關權限策略； 監控配置管理過程； 項目負責人可以查看該項目配置庫中配置項，在允許的權限內可以對配置項進行增、刪、 改。 .3.3.配置管理員（配置管理員（cmocmo） 各項目組指定配置

16、管理員，配置管理員根據配置管理計劃執行該項目各項配置管理任務， 其具體職責為以下幾項： 編制、提交配置管理計劃； 嚴格管理配置項的操作權限； 執行版本控制流程； 執行變更控制方案； 建立開發人員的工作空間； 對開發人員進行相關的培訓； 項目小組開發協作管理； 各配置項的日常管理與維護； 識別配置管理過程中存在的問題并擬就解決方案； 向配置經理、項目負責人定期匯報項目組配置管理情況。 配置管理員可以查看該項目配置庫中配置項，在允許的權限內可以對配置項進行增、刪、 改。 .3.4.開發人員開發人員 開發人員的職責就是根據軟件配置管理計劃和相關規定，按照軟件配置管理工具的使用 方式來完

17、成開發任務。 開發人員可以查看、修改項目配置庫中有權限的配置項，但不允許對配置項進行永久刪 除操作。 .3.5.軟件測試人員軟件測試人員 軟件測試人員的職責就是根據軟件配置管理計劃和相關規定，按照軟件配置管理工具的 使用方式來完成軟件測試任務。 軟件測試人員可以查看軟件的相關開發文檔，在權限范圍內可以對配置項增加、修改， 但不允許對配置項進行永久刪除操作。 .3.6.軟件維護人員軟件維護人員 軟件維護人員的職責就是根據軟件配置管理計劃和相關規定，按照軟件配置管理工具的 使用方式來完成軟件維護任務。 軟件維護人員可以查看、修改該人員負責維護的軟件的相關開發文檔、源程序

18、，在權限 范圍內可以對配置項增加、修改，但不允許對配置項進行永久刪除操作。 .3.7.質量保證人員質量保證人員 質量保證人員的職責就是根據軟件配置管理計劃和相關規定，按照軟件配置管理工具的 使用模型來完成質量保證任務。 質量保證人員可以查看軟件的相關開發文檔，在權限范圍內可以對配置項增加、修改， 但不允許對配置項進行永久刪除操作。 .3.8.角色、權限圖角色、權限圖 以下角色、權限圖主要針對 vss 配置管理工具。 角色 project 配置經理 項目經理配置管理員開發人員軟件測試人員質量保證人 員 準備階段 rrcarcad r (ca 授權) r r (ca 授

19、權) 需求分析階段 rrcarcad r (ca 授權) rr 系統設計階段 rrcarcad r (ca 授權)無 r 系統實現階段 rrcarcad r (ca 授權)無無 系統測試階段 rrcarcadrcarcar 系統維護階段 rrcarcad r (ca 授權)無 r 質量保證 rrrcadrrrca 項目管理 rrcarcadr 無 r 配置管理 rrrcadrrr 測試管理 rrrcadrrcar 個人工作庫 r 無 rcadrcad 無無 項目共享庫 rrcarcadrrr 項目基線庫 r r (ca 授權) rcad r (ca 授權)r (ca 授權) rca 注： 1.

20、權限 r表示具有 read 權限。 c表示具有 check in/check out 權限。 a表示具有 add/rename/delete 權限。 d表示具有 destroy 權限。 無表示不具有該項權限。 授權表示需要項目負責人根據需要配置相應權限。 2.由于配置管理員具有最高權限，可以進行任何操作，但執行非 read 操作時必須經 項目負責人同意。 3. 個人工作空間允許擁有者進行任何操作，包括 destroy 操作。 1.4.配置管理過程配置管理過程 開 始 配置管理策劃 評審 不通過 建立配置管理環境 通過 配置、標識和 管理 變更控制版本控制 基線審核和發 布 報告狀態 發布產品

21、結束 配置管理的策劃由項目組配置管理員負責，策劃的結果為配置管理計劃； 配置管理策劃的評審由開發部配置經理、項目經理進行評審，形成相關的評審紀錄； 配置管理環境由開發部配置經理負責； 配置庫的具體管理由配置管理員負責，形成相關的記錄，包括配置項信息登記表 、配置管理周報、配置管理工作表、軟件配置管理評分表、變更申 請記錄表、應用軟件版本發布申請表、版本記錄表、變更文件審批與 確認登記表。 1.5.配置管理工具及環境配置管理工具及環境 .5.1.文件服務器文件服務器 在開發部建立獨立的文件服務器，文件服務器的主要作用為： 提供共享程序服務 將常用應用程序（包括開發工具、數據庫工具、

22、管理工具等）存放共享目錄下，方便各 開發人員隨時使用，并提供共享目錄以便各開發人員上傳共享程序。 提供共享資料服務 將常用資料存放共享目錄下，方便各開發人員隨時使用，并提供共享目錄以便各開發人 員上傳共享文檔。 提供開發人員個人空間 為每個開發人員建立個人目錄，開發人員可將關鍵文檔在文件服務器上進行備份。此為 開發人員的私有目錄，別人無權訪問。 .5.2.配置管理工具配置管理工具 可采用以下配置管理工具： microsoft visual sourcesafe(vss) 基于 windows 的開發采用 microsoft visual sourcesafe(vss)作為配置管理

23、工具。 基于 unix 下的開發采用 samba 作為磁盤映射工具，microsoft visual sourcesafe(vss) 作為配置管理工具。 cvs 工具 基于 unix 下的開發采用 cvs 作為程序版本控制工具，同時在 windows 環境下 用vss 建立項目文檔等配置項的管理環境。 .5.3.配置服務器配置服務器 在開發部建立統一的配置服務器，逐步進行配置庫的集中管理，項目組內部不再單 獨設立配置服務器。 配置服務器今后將成為軟件開發的項目庫，記錄所有軟件開發項目的開發及維護過 程。對新項目的開發，項目負責人可以申請查閱配置庫中相類似的項目資料，以更好地 把握

24、新項目的開發。 配置服務器也是開發部的公用程序庫服務器。各項目組在項目開發過程中有義務將 通用的程序模塊放入公用程序庫中，被其他項目組使用，達到程序共享，避免重復開發。 公用程序庫的建立及維護見第八章。 1.6.配置管理計劃配置管理計劃 配置管理計劃應細化以下內容： .6.1.配置工具的選擇配置工具的選擇 配置管理計劃中明確采用的配置工具，如采用 unix 下的 cvs 工具，還必須編寫完善 的配置操作腳本，并注明使用方法。 .6.2.配置庫的基本目錄結構配置庫的基本目錄結構 根據具體的項目設置配置庫的基本目錄結構，并進行基本的解釋，一般可以包含以下的 一級目錄及二

25、級目錄： 01 項目工作庫 01 準備階段 02 需求分析階段 03 系統設計階段 04 系統實現階段 05 系統測試階段 06 運行推廣階段 07 系統維護階段 02 項目管理庫 01 質量保證 02項目管理 03配置管理 04測試管理 03 項目共享庫 01 項目模版 02 項目規范 03 項目制度 04 共享資料 04 項目基線庫 01 計劃基線 02 需求基線 03 設計基線 04 產品基線 05 個人工作庫 下設每個項目組成員的目錄 06 其他 .6.3.權限設置權限設置 明確項目組成員對各配置目錄的操作權限。 .6.4.配置項標識規定配置項標識規定 根據

26、項目規模和實際情況的不同，在項目的配置管理計劃中詳細規定配置項標識的命名 規則。 .6.5.協作開發規定協作開發規定 在項目的配置管理計劃中，必須對項目組的協作開發作相應的規定，比如，項目成員每 日的工作是否必須提交？更改了公用頭文件如何通知項目組成員？等等，具體項目具體規定。 .6.6.其它其它 1.7.配置項管理配置項管理 配置項是配置管理的對象，主要包括各種開發/測試文檔、源程序、測試腳本、關鍵數 據、項目報告、會議紀要等。通過建立配置庫對配置項的維護、變更等進行管理，對配置項 要進行統一的配置標識管理及名稱管理。配置標識就是為產品的結構、產品的構件及其類型，

27、 分配唯一的標識符，具體項目可根據項目規模和實際情況的不同，在項目的配置管理計劃中 進一步補充、刪減、細化配置項標識的命名規則。開發部的配置項標識及名稱總體規則如下： .7.1.配置項標識號命名規范配置項標識號命名規范 配置項標識號命名規則： 項目名標識-配置類別-子系統標識-組成部分標識-模塊標識-配置項特殊標識， 其中中的內容可根據系統規模和實際情況有所省略，項目名標識、配置項特殊標 識一般是約定俗成的英文代碼名。 下表列出了我們在項目中使用的配置類別命名： 配置類別配置類別說明說明常用配置項特殊標識舉例常用配置項特殊標識舉例 pdp(project development

28、plan) 項目開發計劃 cmp(configure management plan)配置管理計劃 qap(quality assurance plan)質量保證計劃 frr(feasibility research report)可行性研究 init準備階段其他文檔準備階段其他文檔 crs(client requirement statement)客戶需求 srs(software requirement statement) 需求規格說明書 ra(requirement analyse)需求分析階段其他文檔需求分析階段其他文檔 eis(external interface statemen

29、t)外部接口規范說明文檔 hld(holistic design)概要設計文檔總體方案：-totle dds(detail design statement)詳細設計文檔 dbd(database design)數據庫設計文檔數據字典：-dictionary design 設計階段其他文檔設計階段其他文檔 軟件架構設計： -architecture；階段計劃： -plan；階段總結報告： -summarize scode(source code)源代碼文件 ecode（executable code）執行代碼文件 cf(configure file)配置文件 code實現階段其他文檔實現階段其

30、他文檔 階段計劃：-plan；階段總結 報告：-summarize utest(unit test)單元測試文檔單元測試記錄：-record itest(integration test)集成測試文檔集成測試記錄：-record test測試階段文檔測試階段文檔 測試計劃：-plan；測試方案： -scheme；測試案例：-case 測試記錄：-record；測試問 題：-problem；測試分析報 告:-summarize man軟件說明書和手冊 操作手冊：-operate；用戶手 冊：-user；維護手冊：- maintenance；安裝手冊：-setup issue產品發行文檔產品發行文

31、檔發行記錄：-record delivery交付階段文檔交付階段文檔 switch切換階段文檔切換階段文檔切換方案：-scheme smsyyyymm0199 (software maintain statement) 軟件維護說明書 maintain維護階段其他文檔維護階段其他文檔維護記錄：-record pds(project development summarize)項目開發總結報告 rtm(requirement track matric)需求跟蹤矩陣 cryyyymm0199(change record)變更控制號 pryyyymmddaz(peer review)評審號 trai

32、n培訓記錄和培訓文檔培訓記錄：-record project項目其他文檔 注 1：粗體部分的配置類別是按軟件生存周期的階段劃分的，如配置項具有明確的階段 性，但不屬于某類具體的配置類別，則納入所屬階段的配置類別中；如是貫穿項目多個 階段或歸屬于項目整體的配置項，且不屬于某類具體的配置類別，則納入“project”配置 類別中。 .7.2.配置項名稱命名規范配置項名稱命名規范 開發技術文檔名稱通過項目名稱標識或項目簡稱文檔類別名稱進行命名，主要包括以下文 檔： 可行性研究報告； 項目開發計劃； 配置管理計劃 質量保證計劃； 測試計劃； 程序開發規范； 需求規格說明書； 總體設計說明

33、書； 概要設計說明書； 詳細設計說明書； 數據庫設計說明書； 用戶手冊； 維護手冊； 部分文檔名稱命名時需附加相關信息，主要包括以下文檔： 項目周報：項目名標識或項目簡稱“_項目周報_yyyymmdd” 軟件開發進度月報：項目名標識或項目簡稱“_月報_yyyymmdd” 子項目周報：項目名標識或項目簡稱“_子項目簡稱_周報_yyyymmdd” 質量周報：項目名標識或項目簡稱“_質量周報_yyyymmdd” 會議紀要：項目名標識或項目簡稱“_會議紀要_yyyymmdd” 軟件維護說明書：項目名標識或項目簡稱“_軟件維護說明書_yymm0199” 變更記錄：項目名標識或項目簡稱“_變更記錄_yym

34、m0199” 評審記錄：項目名標識或項目簡稱“_評審記錄_yymmddaz” 說明：斜體部分根據實際情況用相應內容替代。 .7.3.程序文件、數據文件程序文件、數據文件 按項目開發規范要求執行。 1.8.基線建立及變更管理基線建立及變更管理 基線的是已經正式通過審核批準的某階段成果，它可作為進一步開發的基礎，并且只能 通過正式的變化控制過程改變。一般在某階段成果通過評審后，對該成果建立基線，納入基 線管理。（在項目開發的里程碑階段一般要建立項目基線）。開發過程的階段成果可以納入 基線管理的主要有：項目開發計劃、測試計劃、質量保證計劃、業務需求說明書、需求分析 說明書、總體設計說明

35、書、概要設計說明書、程序開發規范、數據庫設計說明書、軟件維護 手冊、用戶手冊、測試案例、已通過測試的軟件版本等。 對項目的每個基線對應一個唯一的標識號。基線標識可采用“bl” +“基線版本號” “-”+“基線日期（yymmdd）表示。 基線類別定義如下：需求基線、設計基線、測試基線、代碼基線 基線版本號由 2 個數字組成，格式為：bl1.0 第一位：對每個基線類型（需求基線、設計基線、測試基線、代碼基線等），都從 1 開始，增改編幅或重要性比例大于 10，則在原來的基礎上加 1。 第二位：增改編幅或重要性比例小于 10，則在原來的基礎上加 1 例如： “bl1.0-050101”表示 進入基線

36、管理的階段成果，是經過評審通過的，配置管理員對其必須進行嚴格的權限控 制，一般只允許讀取，不允許修改，確實需要修改的，執行變更管理流程。 變更管理的一般流程是： a) 獲得/提出變更請求； b) 變更預計影響的評估，包括可能受影響配置項以及對資源、進度、質量等影響 的分析，描述實施方案； c) 項目經理審核并決定是否批準，必要時報請領導批準； d) 如變更請求被接受，由配置管理員從配置庫中檢出配置項，賦予相關人員修改 的權限； e)項目組實施變更，修改配置項的內容，提交確認，如不通過則返回項目組繼續 修改； f)配置管理員回收相關權限，把配置項檢入，形成新基線版本，發布新版本，并 發布變更通知

37、給所有相關人員，包括項目組成員、質量保證人員、測試人員及 其它部門人員等。 1.9.文檔版本管理文檔版本管理 .9.1.文檔版本及版本號的概念文檔版本及版本號的概念 文檔的版本用于區別文檔的不同狀態。每個版本都有唯一的版本號進行標識。版本的概 念對于文檔不同的階段還可以細分為草稿版本（draft versions）、版本（versions）。 草稿版本號：未定稿的文檔的版本號稱為草稿版本號。 版本號：已定稿的文檔的版本號稱為版本號。 .9.2.版本號的定義及生成方法版本號的定義及生成方法 草稿版本號 未定稿的文檔，在經過修改后，如果覺得有需要，可由負責編寫文檔的人員

38、制定出新的 草稿版本號。 草稿版本號由前綴加 2 個數字組成，格式為：draft 0.1 第一位：固定為 0 第二位：在原來的基礎上加 1 草稿版本號的起始標識為：draft 0.1 草稿版本號的變動：第 2 位數字在原來的基礎上加 1。 例如： draft 0.2 - draft 0.3 draft 0.8 - draft 0.9 版本號的生成 定稿的文檔，每次的修訂后，視文檔的重要性由不同權限的人員制定出新的版本號。一 般的文檔或者重要文檔中的單個文檔是可由負責編寫文檔的人員制定出新的版本號。重要的 文檔如需求規格說明書詳細設計等階段性文檔，由項目配置管理員與項目經理協商， 在征得項目經理

39、同意后制定出新的版本號。 版本號由前綴加 2 個數字組成，格式為：ver 1.0 第一位：增改編幅或重要性比例大于 10 第二位：增改編幅或重要性比例小于 10 版本號的起始標識為：ver 1.0 版本號的變動：根據其實際情況選擇相應位置的數值加 1，并將該位置右邊的所有數值 置 0。 例如： ver 1.1 - ver 1.2 .9.3.定版的具體操作方法定版的具體操作方法 文檔的定版必須在文檔開始處按模板要求填寫表格。并在 checkin 到 vss 時將該版本 的改動內容填寫到 comment 中。同時還要遵照變更文件審批與確認的規定執行（詳見本文 相關段落）。 1.9.4

40、.1.9.4.定版的具體操作方法定版的具體操作方法 示例 1，文擋封面處： xxx 系統系統 需求規格說明書需求規格說明書 示例 2，文擋信息部分： 文檔編號版本號密級 xxx-srs1.1秘密 sun trend 中山市森創公司 開發部文檔 名稱：xxx 系統_需求規格說明書共 120 頁 修訂歷史記錄 日期日期版本號版本號修訂內容修訂內容修訂人修訂人評審號評審號變更控制號變更控制號 2010.06.090.9新建張三 2010.06.121.0 根據評審問題修改 章節 1.1.3 張三xxx-pr20040612 2010.07.081.1在 1.2.4 中在增 加 張三xxx-cr200

41、40601 1.10. 軟件版本管理軟件版本管理 .10.1. 定版的具體操作方法定版的具體操作方法 版本用于區別軟件產品的不同狀態。每個版本都有唯一的版本號進行標識。版本的概念 對于不同的軟件產品和不同的階段還可以細分為測試版本（test versions）、版本 （versions）。 測試版本號：提供測試的可執行文件的版本稱為測試版本號。 版本號：通過測試的可執行文件的版本稱為版本號。 秘密/機密/絕密當前版本號 .10.2. 版本號的定義及生成方法版本號的定義及生成方法 測試版本號 可執行文件的各部分通過單元測試，總體編譯通過，由項目配置管理員與項目經理

42、協商， 在項目經理同意下制定出新的測試版本號。 測試版本號由前綴加 2 個數字組成，格式為：test 0.1 第一位：固定為 0 第二位：在原來的基礎上加 1 測試版本號的起始標識為：test 0.1 測試版本號的變動：第 2 位數字在原來的基礎上加 1。 例如： test 0.2 - test 0.3 test 0.18 - test 0.19 版本號的生成 可執行文件的各部分通過單元測試，總體編譯通過，并通過了系統測試，由項目配置管 理員與項目經理協商，在項目經理同意下制定出新的版本號。 版本號由前綴加 4 個數字組成，格式為：ver 其中，后兩個數字可選，即如果后兩個數字

43、同時為 0 時，可以同時省去。但版本號一 定是兩個或四個數字。 第一位：系統整個框架性設計改動或者業務功能的增改編幅或重要性比例大于 10 第二位：系統部分設計改動或者業務功能的增改編幅或重要性比例大于 5 第三位：系統的代碼改動或者業務功能的增改編幅或重要性比例小于 5 第四位：對系統的 bug 修改或者業務功能的增改編幅或重要性均微小。 版本號的起始標識為：ver 1.0 版本號的變動：根據其實際情況選擇相應位置的數值加 1，并將該位置右邊的所有數值 置 0。如果在同一次的修訂中，同時出現兩個或以上位置的數值都符合改變的情況時，只 需按照符合條件的最左位的數值加 1，并將該位置右邊的所有數

44、值置 0。如果后兩個數字同 時為0 時，可以同時省去。 例如： ver - ver - ver 1.2 ver - ver ver - ver ver - ver .10.3. 定版的具體操作方法定版的具體操作方法 每個項目必須有一份版本記錄表。當需要生成一個測試版本時，填寫測試版本一欄 信息。當某一個測試版本通過了測試，有條件生成一個版本時，在該測試版本所對應的一行 中填上版本一欄信息。當某一個版本需要發布，在該版本所對應的一行中填上發布一欄信息

45、測試版本號和版本號均由項目配置管理員與項目經理協商，在項目經理同意下制定。 版本號欄可根據實際情況填寫，發布版本號為空。 版本類型欄選擇填寫以下之一：測試版本、版本、發布。 對于測試版本的注釋欄填寫該測試版本與上一測試版本的不同之處，對于版本的注釋欄 填寫該版本對應的測試版本號以及與上一版本的不同之處，對于發布的注釋欄填寫該版本發 布對應的版本號以及對生產的影響等情況。 項目負責人欄電子文檔填寫項目負責人姓名，紙質文件由項目負責人簽名。 配置管理員欄電子文檔填寫項目配置管理員姓名，紙質文件由項目配置管理員簽名。 其他相關人員欄如有需要電子文檔填寫其他相關人員姓名，紙質文件由其他相關人員簽 名。

46、其他相關人員如公司經理。 項目配置管理員負責填寫版本記錄表，并對vss 庫中的源代碼加上版本號并填 上注釋。 版本記錄表 項目名稱： 序號版本號定版日期版本類型注釋項目負責人配置管理員其他相關人員 .10.4. 在在 vssvss 上定版的具體操作方法上定版的具體操作方法 在 vss 上，可以通過加 lable 的功能實現對系統中所有的源代碼文件進行加版本號的 管理。 當需要加測試版本號是，選擇所有源代碼的最高一級目錄，為其加上 lable，lable 為： test0.1（0.1 為具體的測試版本號），并在 comment 中填上該測試版的定版日期和注釋。 操作完成后，vss

47、 對該目錄一下的所有子目錄及文件均加上相同的 lable 和 comment。 當需要加版本號時，選擇所有源代碼的最高一級目錄，按右鍵并選擇顯示歷史信息，然 后在信息中選中標有該版本對應的測試版本號的 lable，雙擊。在回顯框上，修改 lable， 加上當前的版本號，修改后的 lable為：test0.1ver（0.1為具體的測試版本號, 為具體的版本號），并在 lablecomment 中填上該版本的定版日期和注釋。操作完成后，vss對該 目錄一下的所有子目錄及文件均改為相同的 lable 和 lablecomment。 當某一版本需要發布時，按上述操作，選擇

48、對應的 lable，并在相應的 lablecomment 中加上發布日期及注釋。 1.10.5.版本發布流程版本發布流程 項目組軟件版本發布流程如下圖所示： 序號序號 流程流程 責任人責任人相關人員相關人員文件文件/ /記錄記錄說明說明 a01 配置管理 員 配置管理 員 、軟件 開發人員 用戶測試 報告、開 發、維護文 檔、應用 軟件版本發 布申請表 開發及維護文 檔必須存放項 目配置庫中 a02 各項目部 門負責人、 局領導 項目經理、 開發人員 應用軟件 版本發布申 請表 嚴格審核出部 門、公司的技 術文檔。 a03 配置管理 員、 相關 部門 項目經理 軟件版本、 技術 資料 a04

49、軟件接收 部門 開發人員書面通知書內容包括：版 本發布原因、 版本業務功 能、安裝時間、 影響范圍、安 裝后業務驗證 內容 a05 項目負責 人 開發人員必要時提供現 場技術支持。 a06 用戶、測 試組 開發人員業務驗證測 試報告 根據需要進行 a07 項目負責 人 維護人員、 開發人員 必要時現場技 術支持 a08 開始 a01提交版本發布申請 a02審核版本發布申請 a03版本交付 是否需要業務 部門驗證測試 a04業務驗證測試通知 是 a05版本安裝技術支持 否 a06業務驗證測試 a07系統運行技術支持 a08保存版本 結束 配置管理 員 綜合人員光盤可備份配置庫 時進行備份 1.1

50、0.6. 版本保存版本保存 配置管理員必須保證發布版本源程序的完整性及一致性，質量保證人員保證發布版本的 文檔的完整性，配置經理及對每一次發布的版本，在配置庫中對應地建立版本標識，隨配置庫備份 刻錄光盤時，交綜合人員登記并永久保存，綜合人員應在光盤標簽上標注光盤內容、備份時間、提 交人員，以便查閱。對光盤的查閱必須經部門負責人同意。 1.11. 公用程序庫的建立及維護公用程序庫的建立及維護 公用程序主要包括： 公用函數模塊：提供某一特定功能。 公用類模塊：提供具有通用性的類的定義及方法實現。 加密模塊：各項目組涉及加密的功能模塊由專人開發。 自行開發實用工具：各項目組開發的實用工

51、具。 實現某一功能的完整程序；例如采用 socket 的通訊程序。 具有普遍實用的程序框架；例如 sco unix 下終端程序框架。 其他； 各項目組在項目開發過程中應注意提煉公用程序，共同建設好公用程序庫，為今后的項 目開發省時省力。配置經理建立及維護公用程序庫，接受、審核公用程序，定期公布公用程 序清單。項目負責人可以根據需要提出使用公用程序的申請，部門負責人審核同意后，配置 經理提供相應程序。 1.12. 配置庫的安全管理配置庫的安全管理 .12.1. 版本保存版本保存 項目負責人必須明確每個項目成員的操作權限，對配置項的永久刪除權限必須嚴格控制。 .12

52、.2. 配置服務器的安全控制配置服務器的安全控制 配置經理負責配置服務器的系統管理，不允許其他人登錄配置服務器進行操作。配置經 理必須做好配置服務器的病毒防范及網絡安全控制。 .12.3. 配置庫備份配置庫備份 配置經理負責進行配置庫的備份，主要有： 1)每日備份 每日下班前，配置經理備份配置庫中所有配置項，每周循環。 2)每月備份 配置經理每月定期備份文件服務器的共享目錄及配置服務器中配置庫文件，刻錄光 盤由綜合人員存放，填寫配置庫備份登記表。 .12.4. 配置管理平臺維護配置管理平臺維護 配置經理負責配置管理平臺的維護，填寫開發部配置管理平臺維護日志、配置

53、管 理平臺信息表，具體包括： 建立項目配置庫； 維護相關人員的權限： 系統軟件升級； 病毒防范； 系統資源維護； 1.13.工作空間管理工作空間管理 整個配置庫是一個統一的工作空間，可以進一步劃分為個人空間、項目組空間和共享空 間這三類工作空間。個人空間是開發人員的私有工作空間，開發人員在自己的個人空間進行 開發活動，不會受到他人的影響，也不會影響到其他開發人員，在個人開發空間開發出的成 果，最終提交到項目組空間中。項目組空間是開發團隊的成果空間以及團隊共享空間，對項 目組空間的配置項的操作，配置管理員必須做好權限控制及協調管理。共享工作空間是項目 組中子項目組共同工作的空間，子項目組成員擁有

54、對該空間的讀寫權限。共享工作空間根據 需要建立。 配置管理員及項目負責人必須做好工作空間的分配及管理。 1.14.變更文件的審批與確認變更文件的審批與確認 為了規范化管理，明確責任，避免風險，項目組要做好變更文件的審批與確認工作。 規定每個項目一本變更文件審批與確認登記表，在項目啟動時由項目經理負責建立， 填寫好項目名稱和相關職責人員姓名。 在項目開發生命周期內，由項目組配置代表管理，不得遺失和毀壞。 屬于下列情況之一者，必須有相關人員在變更文件審批與確認登記表上簽字： 項目的各項計劃的制定需要主管部門經理審批，并得到相關部門、相關組或客戶的 確認。 對用戶需求進行分析整理而成的文檔需要經過相

55、關組和部門的確認，并得到用戶的 認可。 各個階段的技術文檔要得到相關組和個人的認可。 項目組內所有的變更要得到項目經理的認可。 涉及到資源、約定的變更要得到主管部門經理的批準，并和相關部門進行協調確認。 所有的變更要通知所有受影響的組和個人。 工作產品交接需要相關人員確認。 工作匯報或狀態報告需要上級主管確認。 凡簽名者，均對相關內容負責，包括風險、保密和責任等方面。如果不能承擔責任者， 則需要報送高一級經理批準。 簽名者必須用黑色墨水筆認真書寫自己真實、完整的姓名，不得隨意涂改。 在項目交付完成后，將變更文件審批與確認登記表交開發部綜合人員歸檔保存。 2軟件質量保證規范軟件質量保證規范 2.

56、1 概述概述 2.1.1 目標目標 本文檔依據 cmm 2 級中軟件質量保證的要求并結合公司軟件開發實際情況對軟件開發 項目建立一套可操作的質量保證規范,其目標是以獨立審查方式，從第三方的角度監控軟 件開發任務的執行,就軟件項目是否正遵循已制定的計劃、標準和規程給開發人員和管理層 提供反映產品和過程質量的信息和數據，提高項目透明度，同時輔助項目組取得高質量的軟 件產品。 2.1.2 方針方針 質量保證工作必須嚴格按照質量保證規范實施和管理； 質量保證實施過程中所有有效記錄必須納入配置管理； 質量保證實施過程中軟件產品、軟件過程中存在的不符合問題必須得到處理，必要 時將問題反映給部門領導； 質量

57、保證人員必須熟悉各種標準及規范，明確影響產品質量的各種活動； 質量保證人員必須獨立于項目組外，從第三方的角度監控軟件開發任務的執行。 2.1.3 核心內容核心內容 規范項目開發過程：按照公司的項目管理方法和軟件開發過程規范，并針對本項目 的實際情況，制定項目開發過程規范。 明確項目各項制度，建立良好的溝通機制 。 嚴格項目計劃：制定明確的軟件開發計劃（包括各階段計劃），并進行必要的跟蹤。 明確項目開發過程中各類角色的職責，為項目成員提供培訓，確保項目成員具備實 施項目的能力 。 加強需求管理：需求是項目計劃和所有活動的基層和依據，加強需求跟蹤 。 加強項目階段成果評審，評審通過后的成果，納入基

58、線管理，嚴格執行變更控制流 程。 加強項目質量控制和質量保證，設立專門的、獨立的測試小組和質量保證小組（質 量保證人員）。 2.2 質量保證活動組織與職責質量保證活動組織與職責 2.2.1 質量保證組織結構圖質量保證組織結構圖 項目的質量保證活動涉及到項目所有成員，具體結構如下： 部門領導 專家組 質量保證組 項目開發組測試組 子 項 目 組 子 項 目 組 2.2.2 角色與職責角色與職責 在質量保證活動中各角色的職責如下： 部門領導部門領導 為項目實施及質量保證活動提供資源； 對質量保證組報告中項目組內無法解決的問題予以支持、解決。 專家組專家組 參與本項目各階

59、段成果評審，為項目組提供業務和技術支持。 質量保證負責人質量保證負責人 負責軟件項目開發質量體系的建立； 各項目質量保證人員的指派； 負責質量保證計劃維護和關鍵質量保證活動的審核認可； 將項目組內部無法解決的問題向部門領導報告，督促、申請幫助解決； 負責在質量保證活動實施過程中，逐步改進軟件開發質量體系過程； 指導各項目組質量保證人員的質量保證工作。 質量保證人員質量保證人員 結合項目情況和軟件開發質量體系，配合項目負責人制定項目規范； 負責編制項目質量保證計劃，提交質量組評估報告； 跟蹤監督項目及各子項目小組的實施過程，驗證評審參與人的資質，監督評審過程 是否符合

60、規范要求； 代碼走查（從規范性的角度）； 監督項目過程中的配置管理工作是否按照項目最初制定的配置管理計劃和相關規范 進行； 質量保證人員幫助項目開發組、各子項目組發現問題，就問題與項目組達成一致， 督促項目組內部解決，無法內部解決或多次跟催仍沒有得到解決的，向質量保證負 責人報告，申請幫助解決； 在質量保證活動實施過程中，收集新方法，提供過程改進的依據。 配置管理人員配置管理人員 編制和維護項目配置管理計劃； 配置庫的權限設置、空間管理與維護； 對開發人員進行相關的配置管理規程指導和培訓； 識別配置管理過程中存在的問題并擬就解決方案； 代碼走查，主要檢查已實現功能模塊是否和需求一