CMMI5在小型項目中的成本過高，根據自己對CMMI5的實施體會與在實際項目中的應用，在項目實施的過程中精簡了CMMI5的實施流程和部分文檔，這個精簡的流程在項目實施的過程中既可以確保流程規範與質量信賴又可以節約項目成本。以下跟大家分享一下CMMI5在項目中的精簡應用：
一、需求與規範的管理
1、由測試負責人（或專門的需求分析負責人）統一接收來自移動總的行業網關相關規範和新需求，測試負責人瀏覽規範獲知大意後回覆郵件，將規範和新需求轉發給開發經理、項目經理、相關的開發人員和測試人員，同時commit到CVS；
2、測試負責人（或專門的需求分析負責人）、項目經理仔細閱讀規範與需求後，對規範和新需求進行研究，並就難點和疑點進行討論，整理出重點內容，並將重點內容發給開發經理、項目經理、相關的開發人員和測試人員，同時commit到CVS；
3、開發經理、項目經理、測試負責人、需求分析負責人、相關的開發人員與測試人員開會對規範、需求和重點內容進行討論，確定需求的具體含義以及最終實現的需求和功能點；
4、項目經理根據規範、需求和開會討論結果編寫《需求規格說明書》與《功能列表》，測試負責人（或專門的需求分析負責人）對文檔進行檢查並修改完善，然後commit到CVS；
5、測試負責人（或專門的PPQA）確認所有相關文檔經過了評審並都已經commit到CVS。
二、項目計劃與測試計劃
1、由開發經理組織項目計劃討論會，在討論會上各開發負責人對自己所負責的模塊所需要的工作量進行評估，根據工作量和工程需求初步確定總體開發計劃、測試計劃和發佈時間；
2、項目經理根據估算工作量和工程需求編寫項目計劃，使用CMMI5總體測試計劃模板並對其進行適當的裁剪和補充，編寫適合本項目的項目計劃；
3、測試負責人根據項目計劃與發佈時間編寫測試計劃，使用CMMI5總體測試計劃模板並對其進行適當的裁剪和補充，編寫適合本項目的測試計劃；
4、項目計劃與測試計劃編寫完成後發送給開發經理、項目經理、相關的開發人員和測試人員，開發經理、項目經理、相關的開發人員和測試人員閱讀項目計劃、測試計劃後將建議和意見以郵件的形式反饋給項目經理與測試負責人，項目經理與測試負責人收集大家的郵件分別對項目計劃與測試計劃進行修改完善，同時回覆郵件說明項目計劃與測試計劃修改情況，如果存在爭議則召開一個小型會議對異議進行討論，修改後的項目計劃、測試計劃commit到CVS；
5、測試負責人（或專門的PPQA）確認所有相關文檔經過了評審並都已經commit到CVS。
三、開發設計與評審
1、項目經理構思系統設計，項目組開發成員一起討論系統的設計，對設計形成較爲清晰的思路；
2、項目經理負責編寫概要設計文檔，與開發經理、開發團隊成員與測試負責人一起討論概要設計；
3、概要設計完成後，項目經理編寫詳細設計文檔、數據庫設計文檔和編碼規範，各模塊負責人負責編寫所負責的模塊進行詳細設計；
4、設計文檔編寫完成後，發郵件通知開發經理、項目經理、測試負責人、相關開發人員和測試人員；
5、開發經理、項目經理、測試負責人、相關開發人員和測試人員對所提交的概要設計文檔、詳細設計文檔進行審查，將建議和意見以郵件的形式反饋給模塊負責人；
6、模塊負責人收集郵件中的修改建議並對設計文檔進行修改，同時回覆郵件說明詳細設計修改情況，修改後的詳細設計commit到CVS；
7、如果對設計存在爭議或出現明顯不合理的設計，召開一個小型會議對異議進行討論，有效解決設計所出現的分歧；
8、測試負責人（或專門的PPQA）對開發最終修改的詳細設計計劃進行檢查，並確認所有文檔都已經commit到CVS。
注：在大型的項目中，必須先完成概要設計後再完成詳細設計，在小項目或需求中可做適當剪裁概要設計與詳細設計合在一起完成。
四、測試方案與評審
1、在項目的設計階段，測試負責人根據規範文檔、功能列表和概要文檔編寫總體測試方案與性能測試方案；
2、測試方案編寫完成後，發郵件通知開發經理、項目經理、相關開發人員和測試人員；
3、開發經理、項目經理、測試負責人、相關開發人員和測試人員對所提交的測試方案進行審查，開發經理和項目經理對測試方案進行總體性的審查，而各模塊負責人則負責相關模塊或功能的測試方案的審查，將建議和意見以郵件的形式反饋給測試負責人；
4、測試負責人收集郵件中的修改建議並對測試方案進行修改，同時回覆郵件說明測試方案修改情況，修改後的測試方案commit到CVS；
5、測試負責人（或專門的PPQA）對最終修改的測試方案進行檢查，並確認所有文檔都已經commit到CVS。
五、編碼實現與單元測試
1、在產品詳細設計完成後，開發工程師依據設計進行編碼工作；
2、編碼完成後，開發工程師編寫單元測試案例並進行單元測試，單元測試完成後提交單元測試報告；
3、項目經理根據項目實際情況對開發工程師編寫的代碼組織Code Review，記錄相關問題；
4、產品模塊單元測試完成後，開發之間進行產品聯調測試，並修改所發現問題以及提交聯調測試報告；
5、產品初步完成後，在提交測試前進行一次產品演示，參加人員包括開發經理、項目經理、測試負責人、開發工程師、測試工程師、售前工程師與售後工程師，在演示的過程中對產品提出改進建議；
6、各模塊負責人對Code Review以及產品展示所發現的問題進行修改，相關的代碼與文檔commit到CVS；
7、項目經理對編碼完成後的系統進行確認，確保提交測試的系統是可運行的，測試負責人（或專門的PPQA）確認所有文檔和代碼都已經commit到CVS。
六、測試設計與評審
1、在項目編碼階段，測試方案編寫完成後，測試負責人或相關測試人員根據測試方案、規範文檔、功能列表和詳細設計進行測試用例設計；
2、測試案例設計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等，在用例設計中，除了功能測試案例外，應儘量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題；
3、在編寫測試案例的過程中，對於存在疑問的地方或測試重點，主動與開發負責人或項目經理溝通討論，一方面有助於設計完善的測試案例，另一方面也有助於開發進一步清晰編碼思路；
4、測試用例編寫完成後，發郵件給開發經理、項目經理、相關開發人員和測試人員；
5、開發經理、項目經理、相關開發人員和測試人員對所提交的測試案例進行審查，開發經理與項目經理對測試案例進行總體性的檢查，各模塊負責人則負責檢查自己所負責的測試案例，將建議和意見以郵件的形式反饋給測試負責人；
6、測試負責人收集大家的郵件對測試案例進行修改完善，同時回覆郵件說明修改情況，如果存在爭議則召開一個小型會議對異議進行討論，修改後的測試案例commit到CVS；
7、測試用例編寫完成之後需要不斷完善，軟件產品新增功能或更新需求後，測試案例必須配套修改更新；在測試過程中發現設計測試案例時考慮不周，需要對測試案例進行修改完善；在軟件交付使用後客戶反饋的軟件缺陷，而缺陷又是因測試案例存在漏洞造成，也需要對測試案例進行完善；
8、測試負責人（或專門的PPQA）對最終修改測試案例進行檢查，並確認所有文檔都已經commit到CVS。
七、測試實施
1、代碼提交前一天準備相關的測試環境（如服務器或數據庫等），代碼提交後測試人員向Build Master申請打包，並搭建正式測試環境，爲了不做到測試以及確保產品可以跨平臺，每個測試人員各自搭建一個測試環境，每個平臺至少要有一個以上的測試人員負責；
2、測試環境搭建好後進行煙霧測試，如果煙霧測試通過則繼續詳細的功能測試，否則中斷測試並返回給開發；
3、測試人員按照預定的測試計劃和測試方案逐項對測試案例進行測試，在測試過程中發現的任何與預期目標不符的現象和問題都必須詳細記錄下來，填寫測試記錄，在必要的時候協助開發追蹤與修改所發現的問題；如果在測試的過程中發現重大的bug或因爲某些bug導致測試不能繼續，測試中斷並返回給開發；
4、每個測試階段測試結束後，由測試負責人總結測試情況，對測試結果進行分析和下一階段測試測試計劃與可能引進的bug數量進行預測，並提交“測試階段分析報告”，併發送給開發經理、項目經理、相關測試人員和開發人員；
5、開發經理對測試階段分析報告中存在的問題採取恰當的措施和調整相關資源，確保下一階段的開發與測試計劃順利進行；
6、開發對bug進行修改；
7、開發對bug修改後測試人員進行迴歸測試，經過修改的軟件可能仍然包含着錯誤，甚至引入了新的錯誤，因此，對於修改以後的程序和文檔，按照修改的方法和影響的範圍，必須重新進行有關的測試；
8、產品的功能比較完善後，進行產品的性能壓力測試，並根據測試結果進行性能調優；
9、確認測試，在軟件發佈前，對產品進行確認測試；
10、當測試產品達到測試計劃所制定的產品質量目標和測試質量目標，整理產品發佈包和編寫相關文檔，確認發佈包和文檔完整後進行產品發佈。
八、產品發佈
當測試產品達到測試計劃所制定的產品質量目標和測試質量目標，整理產品發佈包和編寫相關文檔，在發佈前對照功能列表進行一次全面的確認測試，確認發佈包和文檔完整後進行產品發佈。對於新產品來說，必要的文檔必須包括：（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實施經驗。