從某一層面來講，上面的這張圖表并不能完全說明問題，這是因為軟件開發管理工具的范圍太大了，比如說ERWin和Power Designer的核心在于數據庫設計，雖然Power Designer也可以作系統架構設計與分析，但是由于歷史的原因使得大家往往僅僅會在數據庫設計的時候才會考慮到它。而Together、Rational Rose/XDE、Rational Software Architect都屬于系統架構設計工具，同時可以關聯到需求與代碼實現的輔助工具。而Visio只能稱之為圖形繪制工具，而絕對不能和上面這三個工具相提并論的，適用Visio做流程規劃和分析都是可以的，但是，它不能做設計，至少到目前比較新的版本為止，它的設計功能都是十分微弱的，這一點連微軟顧問服務部的人都承認Visio與Rose不是同一個檔次上的工具。

這張圖在一定程度上表明了下面幾個情況：

•  對于數據庫建模工具，現在Power Designer的市場分額遠大于ERWin的，而且在平時的開發過程中我們可以看到Power Designer的市場宣傳活動也要比ERWin積極很多，我們很少見到關于ERWin的產品宣傳與推廣。加上Power Designer是一些華人參與開發的，所以，更使得中國人對其有著較深的感情而傾向于使用它。
•  對于設計建模工具，Rational Rose/XDE仍然占據著較大的市場分額，其后續產品Rational Software Architect也分割了10.1%的市場分額，居于第二位。這里可以看到IBM在開發工具方面投入的宣傳力度的確產生了實際的效果，這些在與Borland的Together可憐的1.8%的對比中可以看出。加上Borland近年來不斷傳出的負面效應，尤其是2006年將開發工具部分出售未果最后將之獨立成立公司的情況傷害了大批Borlander的心，這種情況到了2007年Together可能連這1.8%的分額都很難堅持住，相信在國際市場上也會有同樣的負面效應出現。

圖表 ：開發者團隊配置管理工具的種類分布狀況

上表中，微軟的Visual Source Safe占據了半數多的比例（52.2%），配置管理工具上的劃分也可以看到微軟產品簡單易用性的深入人心。誠然，微軟VSS的功能是無法與其他配置管理工具相提并論的。但是，在現階段，中國國內開發團隊在配置管理層面上使用的深度與團隊開發規范化程度較弱的情況下，大家對配置管理工具的要求也是相對較低的。這可以從國內很少有大規模的軟件項目的投入，甚至很多年都很難聽說到這方面的任何消息也是有著很密切的關系的。

對于居第二位占22.8%的ClearCase，它是一個功能強大、十分全面的配置管理工具，它甚至可以用于協調幾百上千人以上的開發團隊，甚至用于萬人以上的團隊配合協作也是可能的�？梢哉f從Visual Source Safe 6來看，VSS6最多實現了ClearCase百分之一的功能。但是，ClearCase由于功能過于強大，使得其配置和管理上相當復雜，基本上沒有經過Rational公司培訓過的人是不可能通過自學掌握ClearCase的配置和管理的。當然，一旦配置好了，ClearCase的使用還是十分簡單的，開發人員基本上不需要學習就可以直接上手。

Borland的StarTeam也是一款優秀的配置管理工具，但是，由于Borland將開發工具獨立出去的行為，將可能使得其開發工具的市場分額逐漸降低。而StarTeam作為一個非主流配置管理工具而言，加上公司推廣力度的減弱，前景更是讓人擔憂。

對于其它這14.1%的分額而言，其中應該大部分都是CVS或者WinCVS的用戶，CVS/WinCVS可以看作是與Rational ClearCase以及Visual Source Safe在國內并列的三大配置管理主流工具了，這一點從下面源代碼管理工具上可以獲得數據來源的支持。

圖表 ：開發者團隊使用源代碼管理方案的種類分布狀況

這張圖和前面那張圖應當屬于從屬關系，因為源代碼管理其實是配置管理的一個子項功能，也是配置管理的核心關注點之一，畢竟軟件開發最后都要落實到代碼上，所有軟件項目的結束都是以源代碼形成的產品或者源代碼自身的交付作為終結點的。

從這張圖上CVS占有31.6%的用戶份額可以證明前面“開發者團隊配置管理工具的種類分布狀況調查”中其它部分的結論。

但是這張圖中缺失的部分是ClearCase等配置管理工具所占有的市場分額，因此需要進行同比變化的分析才能得到較為準確的結論。

Visual Source Safe所占有的38.3%的市場分額說明很多公司對Visual Source Safe的安全性還是存在著較大的疑慮，因此并沒有像作為配置管理工具那樣將源代碼液放置到Visual Source Safe中進行統一的管理。而所有的配置管理工具都擁有項目資源管理的功能，因此代碼并不是項目的全部，所以才會有這樣的比例變化。

從個人管理自己的代碼占有10.1%的比例上可以看出下面兩點：

•  國內軟件行業開發者有很多仍然處于原始的開發狀態下，他們屬于個人開發，因此不使用其他的配置管理工具。而這些較為熟練的個人開發者大都有自己的一套代碼和文檔管理策略，這主要是因為配置管理工具的使用將占用較多的硬盤空間，而對于個人開發者而言，硬盤空間一般都并不是空閑較多的。他們雖然沒有采用任何工具來支持這方面的工作，但是個人的代碼管理策略還是同樣存在的，所以這種現狀仍然是不可避免的。
•  對于企業而言，沒有采用代碼管理工具來實現，只能說明這些企業在管理上的混亂與無序，這也是中國國內大批中小企業的軟件開發現狀決定的。這種企業大部分是依靠關系生存的，通過關系拿到一些項目，然后通過招聘剛畢業或者未畢業的大學生作為廉價勞動力來給他們完成這些項目。這種現象在國內已經持續了十多年，相信在目前的情況下，這種情況還會有十多年的存在空間，所以，這種現象仍然是不可避免的。

圖表 ：開發者團隊進行每日構建的工具分布狀況

每日構建其實是XP的一項很好的實踐，從前面采用XP的42.5%的比例來看，填寫軟件開發工具問卷的有效問卷只有總問卷數的24.1%，通過這三個比例關系可以看出，國內實際上做每日構建的總比例仍然是十分小的。

而每日構建只有在較好的采用迭代開發的情況下才能做到，因為每日構建是迭代化思想在產品發布、測試與構建上結合的產物。而從前面迭代化開發的比例（完全采用迭代為6.4%，以及在“開發者公司或項目組對迭代開發方式的應用狀況”中的分析）來看，這種采用每日構建的起始時間一般也都會在項目的中后期才可能推行，這和極限編程中提到的項目初始就能夠進行每日構建的差別是十分大的，也可以從這里看到中國軟件業的規范化道路還是十分漫長的，仍然有很多技術和方法需要我們去學習去積累去實踐。

圖表 ：開發者團隊對集成頻度的要求分布狀況

軟件團隊的集成頻度可以從一個很好的側面看到軟件開發團隊中團隊內部的交流與溝通的頻率以及相關技術的應用頻度。

在實際的軟件開發中有很多是由集成的頻度可能是相對隨意的，這種隨意是與項目組團隊內的開發進度與用例/用戶故事劃分有關系的，有可能更多的集成是在3天、4天、6天或者沒有較多規律的情況下進行的。而在回答這個問題的時候，很多人都會因為這樣而去選擇每天或者每周，因為這兩者是相對較為接近的。

而每月的集成則是傳統的開發方式下，或者重型軟件過程模型（諸如RUP）下的常規方式，這里從占有20.1%的每月構建可以看到這一點。而這個每小時構建的2.1%與前面的完全采用迭代化開發的6.4%的比例是何其的相似，但是從這里我們可以看到中國軟件業規范化的希望。而從52.6%的每周構建和25.2%的每天構建中，我們看到的更多的是擔憂和國內軟件開發狀態的混亂。
圖表 ：開發者團隊對變更管理和缺陷跟蹤使用工具的種類分布狀況

變更管理和缺陷跟蹤工具的使用一直是國內軟件企業和開發團隊的弱點，這方面大部分企業都是通過自己的內部調整手段來進行實現的，部分企業和團隊將它與需求管理合并起來進行統一的管理，這是因為需求管理主要是針對用戶需求變更的管理，而變更管理與缺陷跟蹤在一定程度上是和需求管理的表現上是相似的。

比如用戶使用系統中遇到的問題提出來，這時候需求調研人員要考慮這是需求變更還是系統缺陷，然后進行分類標記，但是一般都是統一登記并進入后續流程的。在上面對圖表數據中占有四分之一份額的其他選項與需求管理中其他的25.3%的比例非常接近，這一點和需求管理中是相似的：“國內有很多公司和團隊在使用自己開發的需求管理工具。這是由于需求管理有著明確的起始和終結點，過程相對穩定，有著自己獨立完整的工程活動過程，開發難度也較小，所以，很多公司都會根據自己的特點進行同類工具的開發”。

Rational公司在變更管理和缺陷跟蹤工具應用中仍然占有比較大的用戶份額和認可程度，這個原因前面已經陳述過多次了，而Borland StarTeam所占有的20.5%的比例也說明Borlander在國內的數量比例還是很大的，但是，如果Borland繼續下去，這個份額比例估計只能是逐年下降的。

其他的諸如Bugzilla的6.6%、Telelogic Synergy的5.6%和Hansky Butterfly的2.5%都說明在這方面的用戶認同度是相對較為寬泛的，大家接觸的也相對較多，開源工具與商用工具在沒有較大規模市場宣傳影響的背景上可以做到平分“疆土”的程度。