TAJ Technologies公司有過一個項目，用戶指定需要采用面向?qū)ο蠓治?、設計和開發(fā)，且開發(fā)周期短，在無賴的情況下，項目小組只能選用面向?qū)ο蟮能浖_發(fā)過程，由于項目小組很少從事過面向?qū)ο蟮拈_發(fā)，經(jīng)驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。

針對此次開發(fā)，我們分析其原因，發(fā)現(xiàn)小組成員在開發(fā)過程中對于新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關人員發(fā)布，再由配置管理員對其發(fā)布的文檔進行整理、規(guī)類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在這次開發(fā)中我們公司從管理人員、設計人員到開發(fā)人員都汲取了很多教訓，同時經(jīng)過此次項目的開發(fā)，小組成員也積累了豐富的面向?qū)ο蟮拈_發(fā)經(jīng)驗。

除設計選型，還有一個容易被忽視的問題，就是公共類開發(fā)。公共類開發(fā)可以減少工作中的重復工作，降低開發(fā)成本。這要求我們再設計階段通過對用戶需求的仔細研究，盡可能的識別出公共類，并進行定義指定專人負責設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文檔，由質(zhì)保小組組織技術專家、項目組設計人員、開發(fā)人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時確保設計文檔能為開發(fā)人員、測試人員提供切實的指導。對于可復用的設計進行提取作為公共庫設計和開發(fā)，提供項目組或整個公司重用。最后交由配置管理員進行設計文檔的版本控制。

c、實現(xiàn)

實現(xiàn)也就是代碼的生產(chǎn)過程。這里不僅包括代碼的產(chǎn)生，同時也包括測試用例的產(chǎn)生。針對上一階段提供詳細設計，程序員開始編碼并且調(diào)試程序，測試人員則根據(jù)設計進行測試用例的設計，設計出來的用例需要得到項目組成員認可由項目經(jīng)理審核通過才能進入配置庫。同時程序員調(diào)試完程序提交測試人員進行程序正確性檢測。

d、文檔管理
文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。

內(nèi)部文檔包括： 項目開發(fā)計劃； 需求分析； 體系結構設計說明； 詳細設計說明； 構件索引； 構件成分說明； 構件接口及調(diào)用說明； 組件索引； 組件接口及調(diào)用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統(tǒng)計報告； 質(zhì)量監(jiān)督報告； 源代碼； 文檔分類版本索引； 軟件安裝打包文件。
外部文檔主要包括： 軟件安裝手冊； 軟件操作手冊； 在線幫助； 系統(tǒng)性能指標報告； 系統(tǒng)操作索引。

如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。       在本項目的開發(fā)中，配置管理小組的一個非常重要的任務還是書寫文檔規(guī)范和文檔模板。當有文檔模板后需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當他人書寫完畢之后，必須由文檔的初寫者進行復審，復審通過后方可以正式提交，進入軟件配置管理的循環(huán)中。

配置管理小組真正核心的工作是對文檔的組織管理。根據(jù)文檔的不同