软件开发管理工具应用状况
从某一层面来讲，上面的这张图表并不能完全说明问题，这是因为软件开发管理工具的范围太大了，比如说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，它是一个功能强大、十分全面的配置管理工具，它甚至可以用于协调几百上千人以上的开发团队，甚至用于万人以上的团队配合协作也是可能的�？梢运荡覸isual 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%，以及在“开发者公司或项目组对迭代开发方式的应用状况”中的分析）来看，这种采用每日构建的起始时间一般也都会在项目的中后期才可能推行，这和极限编程中提到的项目初始就能够进行每日构建的差别是十分大的，也可以从这里看到中国软件业的规范化道路还是十分漫长的，仍然有很多技术和方法需要我们去学习去积累去实践。
图表 ：开发者团队对集成频度的要求分布状况
.jpg)
软件团队的集成频度可以从一个很好的侧面看到软件开发团队中团队内部的交流与沟通的频率以及相关技术的应用频度。
在实际的软件开发中有很多是由集成的频度可能是相对随意的，这种随意是与项目组团队内的开发进度与用例/用户故事划分有关系的，有可能更多的集成是在3天、4天、6天或者没有较多规律的情况下进行的。而在回答这个问题的时候，很多人都会因为这样而去选择每天或者每周，因为这两者是相对较为接近的。
而每月的集成则是传统的开发方式下，或者重型软件过程模型（诸如RUP）下的常规方式，这里从占有20.1%的每月构建可以看到这一点。而这个每小时构建的2.1%与前面的完全采用迭代化开发的6.4%的比例是何其的相似，但是从这里我们可以看到中国软件业规范化的希望。而从52.6%的每周构建和25.2%的每天构建中，我们看到的更多的是担忧和国内软件开发状态的混乱。
图表 ：开发者团队对变更管理和缺陷跟踪使用工具的种类分布状况
.jpg)
变更管理和缺陷跟踪工具的使用一直是国内软件企业和开发团队的弱点，这方面大部分企业都是通过自己的内部调整手段来进行实现的，部分企业和团队将它与需求管理合并起来进行统一的管理，这是因为需求管理主要是针对用户需求变更的管理，而变更管理与缺陷跟踪在一定程度上是和需求管理的表现上是相似的。
比如用户使用系统中遇到的问题提出来，这时候需求调研人员要考虑这是需求变更还是系统缺陷，然后进行分类标记，但是一般都是统一登记并进入后续流程的。在上面对图表数据中占有四分之一份额的其他选项与需求管理中其他的25.3%的比例非常接近，这一点和需求管理中是相似的：“国内有很多公司和团队在使用自己开发的需求管理工具。这是由于需求管理有着明确的起始和终结点，过程相对稳定，有着自己独立完整的工程活动过程，开发难度也较小，所以，很多公司都会根据自己的特点进行同类工具的开发”。
Rational公司在变更管理和缺陷跟踪工具应用中仍然占有最大的用户份额和认可程度，这个原因前面已经陈述过多次了，而Borland StarTeam所占有的20.5%的比例也说明Borlander在国内的数量比例还是很大的，但是，如果Borland继续下去，这个份额比例估计只能是逐年下降的。
其他的诸如Bugzilla的6.6%、Telelogic Synergy的5.6%和Hansky Butterfly的2.5%都说明在这方面的用户认同度是相对较为宽泛的，大家接触的也相对较多，开源工具与商用工具在没有较大规模市场宣传影响的背景上可以做到平分“疆土”的程度。
