七、客戶驗收
成果審查。驗收人員審查開發方應當交付的成果，如代碼、文檔等等。確保這些成果是完整的并且是正確有效的。
驗收測試。驗收人員對交付的產品進行全面的測試，確保產品功能、質量符合需求。
及時解決客戶方發現的問題。
輸出：
客戶驗收計劃、驗收測試用例、客戶驗收報告、驗收操作手冊
實施建議：
在客戶驗收之前，開發方對驗收人員進行必要的產品培訓。
開發方可以將系統測試用例給驗收人員參考，以減少設計測試用例的時間。
開發方人員應當熱情地協助驗收人員。對驗收人員發現的軟件缺陷馬上予以糾正；對于復雜的問題應當立即請示有關領導，不可拖延。在驗收期間不可與客戶爭吵，給客戶留下很好的印象。
對驗收過程中產生的所有有價值的文檔進行配置管理。
八、結項
計劃與實際情況對比:產品功能、工作成果、產品質量、投入人員、工作量、成本等
申請結項理由和項目自我評價
對項目進行綜合評估，總結經驗教訓。
有價值的結項管理至少包括三項內容：
一、對項目的有形資產和無形資產進行清算，既要防止資產流失，又要及時地利用這些資產。
二、對項目進行綜合評估。例如評估項目完成情況、項目質量、投入產出分析、項目的市場價值、項目對企業的貢獻等等。該評估報告可以作為考核項目人員業績的重要依據。
三、總結經驗教訓，使整個機構受益。
實施建議:
對結項管理過程域產生的所有有價值的文檔進行配置管理。
做好必要的保密工作。
結項評審工作不能簡化。
對結項評審委員會進行必要的培訓，使他們樹立正確的觀念，從而嚴格把關
輸出：
結項申請書、結項評審報告
下面是這些核心工具的運用經驗：
1.必須建立源代碼的版本控制系統，是cvs，基本的代碼提交原則：
1)程序員盡量每天只在下班前提交一次;
2)提交的代碼必須是在自己的機器上是正常運行的；
3)每次提交都必須用簡短的話說明自己提交代碼的功能描述。
2.建立錯誤追蹤系統，用Bugzilla很好，配置好郵件系統，使Bugzilla成為測試人員與開發人員溝通的橋梁。
3.用BAT和Perl腳本，以cvs中的源代碼為核心實現簡單的每日編譯工具，將這個自己寫的自動化工具放到一臺專門的編譯機器上，在每天的半夜開始自動下載代碼，自動編譯代碼，自動打包安裝程序，自動記錄各種編譯日志，自動將安裝程序放置到一個固定的以日期為目錄名的公共區。（用cvs2cl.pl得到程序員上傳的代碼更新日志，以便測試人員參考）
4.測試人員的第二天，應該到公共區取得頭天的新版本，并根據ChangeLog進行新版本的測試。并將測試中發現的Bug，通過Bugzilla反饋給程序員。程序員可以根據自己的情況，或公司的規定來決定修改這些Bug的時間。并將這些Bug的修改情況，在代碼提交時，寫入代碼日志。
5.開發人員的第二天，應該到公共區查看編譯日志，看看自己的模塊是否正常編譯，及時更正，看看自己的郵箱有沒有Bug報告，及時修改。
6.管理人員的第二天，在綜合項目需求與頭天版本進度的上，可以判斷產品的發展方向，如果有偏航或理解錯誤或有新需求時，可以根據當前情況及時調整。
這樣，通過 cvs => bugzilla => daily-build，能將程序員與測試員，進行互動，各施其責。減少溝通與人為的麻煩。對于管理層，也能做到心中有數：因為每天都有新版本，隨時掌握產品的走向。。。等等。
