CMMI5在項目中的精簡應用

　　當測試產品達到測試計劃所制定的產品質量目標和測試質量目標，整理產品發布包和編寫相關文檔，在發布前對照功能列表進行一次全面的確認測試，確認發布包和文檔完整后進行產品發布。對于新產品來說，必要的文檔必須包括：（1） 產品安裝操作手冊;（2） 產品白皮書;（3） 產品管理維護手冊;（4） 用戶操作手冊;（5） 總體測試報告（6）性能測試報告。
 
　　九、版本控制

　　在測試過程中，軟件的打包統一由Build Master完成。新版本軟件發布之后，馬上對代碼進行 質量控制：（1） Build Master給新版本的源代碼打一個cvs tag，方便代碼回滾check out。比如，發布版本為IAGW1.0.0，則給該軟件源代碼也打一個與發布版本相同名字的tag IAGW1.0.0。這樣做的一個好處是，在目前的軟件的基礎上做了修改并發布新的版本后，如果需要check out某個版本的源代碼，則可以通過這個版本的tag來check out，代碼的修改可以在該版本上進行。（2） Build Master對新發布的軟件源代碼進行cvs lock，不允許開發人員在軟件發布之后commit源代碼，直到有新版本需求修改再給開發人員開放commit權限。這樣做的好處是避免開發人員隨意修改和commit源代碼，確保源代碼服務器上的源代碼版本與當前最新的發布版本一致。
 
　　十、自動測試

　　產品穩定后，進行自動 測試工具開發，對于穩定的功能使用自動測試工具進行測試，新增的功能使用手工測試，使用自動測試+手工測試的模式，可以大大提供測試效率。
 
　　十一、小結：應用推廣思路與體會

　　整體思路是：首先對項目進行需求分析，有效的需求分析方法是需求分析人員、 項目經理、開發經理與測試負責人分別閱讀規范與原始需求，特別是需求分析負責人與項目經理，需要對需求進行深入的分析研究，然后開會討論，消除對需求的誤解與遺漏，討論結束后編寫功能列表說明文檔與需求規格說明書并評審；對于規范中不明確的問題集中后由測試負責人（或需求分析負責人）直接與移動總規范負責人直接交流，確保不會因為規范的理解不正確導致項目實現與需求不一致。需求分析完成后，編寫項目計劃書與測試計劃書；項目計劃、測試計劃編寫前先開會討論，由模塊負責人估算工作量，能確定的問題和時間安排都在討論中確定下來，然后根據工作量和工程需求制定項目計劃和測試計劃。開發在編碼前需要進行概要設計和詳細設計，開發工程師在編碼前對系統的總體設計架構、各自所負責的模塊有一個清晰的設計思路，經評審后確認模塊的設計是否合理；開發在編碼完成后在提交測試前必須進行單元測試與聯調測試，提交給測試的軟件是一個可運行的產品。測試工作中，在項目設計或編碼階段，測試負責人對項目進行測試設計，指導測試實施有依可循，在編寫案例的過程中會遇到很多與流程和細節處理相關的問題，與開發一起討論也有助于提前發現問題與完善代碼；在測試實施階段，測試人員記錄所發現的問題，并協助開發及時解決，在測試過程中所遇到的問題，測試負責人進行記錄和分析，在每個階段完成后提交經分析后的測試階段報告，在 軟件測試階段報告中總結分析了測試過程中所發現的問題并對這些問題提出解決建議，在后續的開發與測試中進行改進與調整，確保項目能夠按時保質發布。為了節約 資源，計劃或設計都是以郵件的形式進行評審；對于存在嚴整分歧的問題，組織一個小型 會議進行討論有效解決問題，小型討論會是解決問題的一種有效途徑，任何問題都可以通過face-to-face的交流達到共識。軟件的管理和版本管理則由Build Master負責，確保軟件得到良好的控制。在整個項目實施的過程中，需要有一個PPQA對流程進行檢查與監督。

　　這個精簡的實施流程，不但確保了軟件的質量，而且實施成本較低，在 團隊實施中非常容易推廣。 在整個流程中，測試負責人除了負責測試相關任務以外，同時承擔了需求管理、流程跟蹤、協調 溝通等工作（當然，也可由項目經理或開發經理等擔任），在其中由測試推動項目開發與實現，在開發成員之間、開發與測試之間搭了一座溝通的橋梁，這樣的一個協調與推動促進了項目的順利完成，適合于五至二十的小型團隊。不過這種測試與開發的模式，對測試負責人的要求很高，不但要求測試負責人具有很強的責任心與溝通協調能力，而且還需要具有很高的業務分析能力和 CMMI5實施經驗。

[1]  [2]  [3]  [4]  

原文轉自：http://www.kjueaiud.com