上面的这张图表一方面说明了中国企业开始认同并逐渐将需求管理投入到开发实践过程中，但同时说明了需求管理做得也较为混乱，另一方面说明中国软件开发者面对的用户业务需求的变化实在是很频繁。 

    需求管理真正在中国大陆推行起来的时间应该是2001到2002年间，到现在越来越多的企业开始重视需求管理，并开始将之投入到开发管理实践过程中。但是，在正常的软件开发过程中，需求管理在一个人数为三十人以内的项目组中只需要一个人就可以负责来完成，在一百人以内的项目组中根据不同的项目情况也不需要超过五个需求管理人员，而这里却达到了超过半数的59.8%的比例。这一方面说明中国的软件开发者不得不在各个阶段来面对需求变更的问题，另一方面说明软件开发过程中的需求管理工作仍然相对处于混乱状态，并不是专人负责，职责明确的分工合作，由此可见中国软件业的规范化还有相当长的道路需要走。 

    用户业务需求变化的频繁程度从这里也可以看到，只有当用户需求频繁变化的时候，软件开发者才会因为需要应对需求的变化而不得不与需求管理工作打交道，这也使得软件开发者认为自己都在亲自做需求管理。而当需求相对较为稳定的情况下，软件开发者所面对的需求变更次数不是频繁到必须每一个业务模块的开发者都必须进行多次的需求变更工作。那么，软件开发者就不会都认为自己是亲自在做需求管理工作，因为将这项工作转交给指定的需求管理员也是一种更高效更规范化的操作方式，同时也会减轻自己在开发过程中受到外在影响而不得不改变工作频率导致工作效率降低的一种有效措施。 

    图表 ：开发者采用的管理需求工具的分布状况

    这种需求管理工具使用的分布情况是与各个企业在中国大陆的市场推广与宣传活动有着直接关系的。 

    可以看到Rational公司的RequisitePro工具占据着接近一半的市场分额，这和这几年内Rational公司包括现在的IBM公司在中国大陆的较大规模的市场宣传与推动力度直接关联的，正因为Rational从2000年开始在中国大陆的一系列宣传活动使得国内开发人员对Rational公司的系列工具都有着较为深入的了解和认识，同时也在大面积的试用（注意：这里是试用，而不是使用）。 

    而Borland是老牌的开发工具厂商，在国内有着大量的Borlander的存在使得他们的每一个新工具的推出都会有人进行一些自发的宣传与推广，因此它才拥有了五分之一强的市场分额。 

    而在国际上享有盛名的需求管理工具DOORS，却因为公司在中国大陆的宣传力度的薄弱而只占有可怜的3.2%的市场分额，这还是从2005年开始Telelogic公司在中国大陆开始的宣传活动有些关系的，否则，估计他连1%的市场分额也难以保持。 

    而其它需求管理工具占有的25.3%的市场说明，国内有很多公司和团队在使用自己开发的需求管理工具。这是由于需求管理有着明确的起始和终结点，过程相对稳定，有着自己独立完整的工程活动过程，开发难度也较小，所以，很多公司都会根据自己的特点进行同类工具的开发。

    3 软件开发管理工具应用状况 

    图表 ：开发者对建模工具的使用状况

    从某一层面来讲，上面的这张图表并不能完全说明问题，这是因为软件开发管理工具的范围太大了，比如说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，它是一个功能强大、十分全面的配置管理工具，它甚至可以用于协调几百上千人以上的开发团队，甚至用于万人以上的团队配合协作也是可能的。可以说从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%都说明在这方面的用户认同度是相对较为宽泛的，大家接触的也相对较多，开源工具与商用工具在没有较大规模市场宣传影响的背景上可以做到平分“疆土”的程度。

    这个调查的结果说明了目前国内软件开发人员对软件生命周期各阶段的认同程度和重要性。上图中的内容基本上分为了三个层次：第一层包括强大的团队协作功能、涵盖软件生命周期的各个环节两项都有超过60%的认可度，第二层是管理的可跟踪性与智能化的管理与控制功能有着50%左右的认可度，第三层则包括其他的五项内容。 

    第一层：

•  前者说明国内开发者开始逐渐认同团队协作的重要性，而不再过于强调个人能力与个人英雄主义的思想氛围，由于软件开发本身是一种创造性的工作，这也是很多没有机会获得国家或者其他支持进行科学研究的技术人员投身到软件行业的一个至关重要的原因。
•  后者说明国内开发者已经意识到软件开发本身是需要经历相应的软件生命周期的各个生存环节的，不可能超越或者跨越一些重要的环节直接将代码交付给最终用户。这是与有些极端的极限编程狂者所提出的“代码即文档”的观点的强烈质疑，同样在国外著名的软件工程专家康斯坦丁的《人件集》中也有对“代码即文档”这种观点的直接质疑和反对。

    第二层：

•  说明国内的开发者开始认同软件项目管理的重要性，这也是在十多年的争论和学习以后，国内的开发者终于意识到个人开发与团队开发是两种不同层次的概念，团队开发有着与个人开发无法比拟的优势，而团队开发则比个人开发更要求管理，更加强调了管理的重要性；
•  管理的可跟踪性的超过50%的认同度说明国内的开发者意识到管理是一个循序渐进的过程，它是一个在潜移默化中推动技术进步并在表象上直接推动项目进行的一个因素，管理必须做到可跟踪。否则，这个管理必然是无效的也是混乱的，只有可跟踪的管理才是有序有效的，能够真正对项目的开发产生积极的推动作用。
•  智能化的管理与控制功能所占有的44.3%的比例，说明国内开发者对这方面的期待和对这个功能的不确定性。要知道软件开发完全是人的行为，属于人的意识层面的活动转变为现实的一个过程，这种管理完全是对人的一种管理，同时对用户思维行为的判断与分析。智能化的管理与控制功能对人的影响是否是客观有效的，这是所有软件从业人员所关注的问题，这也是人工智能技术在沉寂了几年后重新进入软件行业被提出后的一种影响。Ivar Jacobson的公司从2004年起将一些人工智能技术放入到软件工程过程的咨询服务之中，创造了Ivar博士的生动小人形象。这些都是软件从业者在智能化管理和控制方面的尝试与努力。

    对于第三层，剩下的内容主要是在企业层面上的关注，这分别覆盖了下面几个方面。

•  安全性：也许可以称安全性为软件开发第一话题。
  
  这也是最近几年众多的黑客活动使得大家对软件和网络安全关注的结果，由于软件开发在一定程度上可以做到与外部网络的物理隔离，所以，它所占的比例并不是十分得高，也不是一个首要的问题。
•  开发流程：增加对开发流程的观测力。
  
  开发过程模型和过程的管理与监督也都获得了开发者的认同。
•  专业化：针对特定行业应用进行优化和针对特定应用类型进行优化。
  
  这是由于各个行业的特性与差异和应用类别的不同使得专业化成为一个非常重要的话题，甚至有人认为：软件开发方法、软件开发过程等相对较为抽象层次的理论也必须根据各个行业进行实际力举才能让相应行业的开发者认同并愿意采用。这也可以从另一个侧面体现出开发者偷懒取巧的心态和企业管理者不愿意投入资金进行人员培养的心态，大家都想拿现成的，而不是经过自己的研究分析后再使用。
  
  当然，人类历史上的任何发明创造都是为了让人类偷懒！但是，大家都知道工具做得越专业市场范围就会越小，企业产品与行业贴得越紧密随着行业的变化，企业的盈亏波动也就会越大，甚至因为行业的微小变化就会让企业破产。
  
  这也使很多企业不敢进入过于专业的软件产品方向进行研发的原因，因为在不太久远的软件发展史上大家都看到了很多类似的经典案例。现在连Borland都认为通用开发工具成为一种累赘，是一个不得不被抛弃的鸡肋，那么谁还敢进入更专业的开发工具的研发中呢？这个问题是值得所有软件行业从业人员思考的大问题。
•  资源管理：具有企业资源管理功能。
  
  这一点说明开发者开始关注团队以外的企业环境和资源，而不是仅仅局限于思考眼前或者身边的一些人和事，如果企业对自己所从事的方向投入不断的减少和降低，或者申请的资源都被拒绝而得不到及时的补充，那么谁都明白：也许自己应该考虑换个环境了。
  
  而从项目管理的角度来看，资源的整合与配置是十分重要的，这一点不需要有任何数据来支持，因为这是显而易见的。试想，一个人完成Windows是多么得不可能，而微软最近在每一个Windows版本开发完成后提供的关于这些人吃掉了多少汉堡、喝掉了多少可乐等等的数据，其实不是在说这些汉堡或者可乐，而是说微软有多少资源在开发Windows的时候被调动起来，通过侧面数据来说明它们的团队协作和公司资源管理与配置方面的优势。