，及時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時確保設計文檔能為開發(fā)人員、測試人員提供切實的指導。對于可復用的設計進行提取作為公共庫設計和開發(fā)，提供項目組或整個公司重用。最后交由配置管理員進行設計文檔的版本控制。
c、實現(xiàn)
實現(xiàn)也就是代碼的生產過程。這里不僅包括代碼的產生，同時也包括測試用例的產生。針對上一階段提供詳細設計，程序員開始編碼并且調試程序，測試人員則根據(jù)設計進行測試用例的設計，設計出來的用例需要得到項目組成員認可由項目經(jīng)理審核通過才能進入配置庫。同時程序員調試完程序提交測試人員進行程序正確性檢測。
d、文檔管理
文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內部文檔和外部文檔。
內部文檔包括： 項目開發(fā)計劃； 需求分析； 體系結構設計說明； 詳細設計說明； 構件索引； 構件成分說明； 構件接口及調用說明；組件索引； 組件接口及調用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統(tǒng)計報告； 質量監(jiān)督報告； 源代碼； 文檔分類版本索引； 軟件安裝打包文件。
外部文檔主要包括： 軟件安裝手冊； 軟件操作手冊； 在線幫助； 系統(tǒng)性能指標報告； 系統(tǒng)操作索引。
如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。在本項目的開發(fā)中，配置管理小組的一個非常重要的任務還是書寫文檔規(guī)范和文檔模板。當有文檔模板后需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當他人書寫完畢之后，必須由文檔的初寫者進行復審，復審通過后方可以正式提交，進入軟件配置管理可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當他人書寫完畢之后，必須由文檔的初寫者進行復審，復審通過后方可以正式提交，進入軟件配置管理的循環(huán)中。
配置管理小組真正核心的工作是對文檔的組織管理。根據(jù)文檔的不同，文檔的來源也不同，有些是通過質量保證小組經(jīng)過復審之后轉交給配置管理小組，有些則會直接從文檔的出處到達配置管理小組。文檔的管理是一個非常煩瑣的工作，但是長遠來看它不僅使項目的開發(fā)對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風險，更重要的是在項目進行到后百分之十的時候起到拉動項目的作用。
從以往做大項目的經(jīng)驗來看，寫作文檔在項目開發(fā)的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進。一個明顯的例子就是系統(tǒng)整合，或者某些環(huán)節(jié)是建立在其他環(huán)節(jié)完成的基礎之上時，就更顯現(xiàn)出文檔交流的準確性和高效性。
3、系統(tǒng)維護質量保證
在我們公司，維護小組的任務一方面是保證對項目客戶的跟蹤服務，另一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來以便投入到下一個項目的開發(fā)中。所以通常項目維護小組成員主要由項目組的少部分開發(fā)人員承擔完成。他們不僅了解軟件的核心內容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當?shù)纫鸬膯栴}，全部由維護小組執(zhí)行完成，但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程，用戶或者維護人員填寫變更申請，經(jīng)專家會議討論分析可行方案在由維護小組實施，通過測試后方可提交用戶。
維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用戶時，在維護小組有較多的人員進行跟進，隨軟件的穩(wěn)定，跟進的人逐步減少，并轉移到其它項目中去。