[技术讨论]中国软件工程技术应用调查报告第四章

序言

这篇文字是应目前在it168工作的原CSDN老哥熊建国之约，基于他们的统计数据作出的调研，因为一些原因，其中修改并了少量文字，这里我把我的全文贴在这里。

目前的已发布文档连接如下：

 http://tech.it168.com/m/p/2007-01-29/200701290911953.shtml  中国软件开发工具应用状况分析

http://tech.it168.com/m/p/2007-01-30/200701300922046.shtml  中国软件质量管理和测试工具的应用状况分析

http://tech.it168.com/m/a/2007-01-23/200701230933790.shtml  中国软件项目开发管理体系建立状况分析

这篇文章被分成了三个部分在it168上作了发布，现在时间已经过了两个月，我可以将我的文章发表在我的blog上了。

注：因为本文较长，所以文中图片没有进行上传，文中的相关图片可以在上面三个连接中看到，给大家带来的麻烦，请多多见谅。

正文

  

第四章 软件开发过程技术应用研究

n 软件开发过程技术应用研究的主要结论：

1.国内软件企业的规范化程度在不断提升

2.软件开发辅助工具的使用日益普及

3.中国软件企业仍然有绝大部分处于原始开发状态，需要真正懂得软件工程技术和管理的技术人员或者国内软件咨询技术企业的成长。

n 软件开发过程技术应用的概况：

中国的软件行业从上世纪八十年代末开始形成，到现在已经经历了将近二十年的时间，这二十年时间里，国际软件行业和技术的革新变化非常之大，我们不得不面对国际软件行业企业已经走过了几十年的历程和经验积累对我们产生的压力。

从下面的调查数据上我们可以看到中国软件行业的从业人员的努力与拼搏，但是，仍然有太多的地方是不如意的，也使得我们中国软件行业的从业人员不得不再次的深入思考，反省我们曾经的做法，规划我们将来的道路。

一组组的数据上到底说明了些什么问题，下面我们会在文中进行详细的分析和讲述。

 

第1节 软件项目开发管理体系的建立状况

参考问卷

　1． 您所在的公司或项目组通过什么样的评估体系认证？ 

 都没有 ISO-9000系列 CMM/CMMI系列 其它 

 

现阶段国内的企业感觉到规范化研发过程的对企业的重要性，目前绝大多数企业都通过了相关的认证评估，其中38%的企业通过了ISO-9000系列的认证，28.2%的企业通过了CMM/CMMI方面的评估，只有32%的企业还没有进行相关的认证评估工作。

　图表 1 开发者公司或项目获得软件评估认证体系的分布状况

 

ISO9000被认为是国内各种类型的企业在规范化进行中必须经过的一种认证，CMM/CMMI评估是2000年开始进入中国大陆并迅速得到各类软件企业认同的一种评估手段。

可以这样说，基本上通过CMM/CMMI评估的软件企业都会先考虑通过ISO9000系列的认证，因为CMM/CMMI评估的费用较大，周期也相应较长。

2000年的时候珠海市宣布对通过CMM评估的软件企业给与一次性50万人民币的奖励，同时国内多个城市都出台了类似的奖励措施。但是，直到2001年底国内也只有几家企业通过了CMM2级的评估，CMM3级的评估只有2家。企业在通过CMM/CMMI评估的过程中，CMM/CMMI2级大约需要100万人民币，而3级的评估则需要150万到200万人民币的投入。现在居然能占到了28.2%的企业中的部门通过了CMM/CMMI的评估，可见国内企业进行这方面认证的投入是相当积极的。

这里有一个需要澄清的观点，那就是：CMM/CMMI只有评估，没有认证！

关于CMM/CMMI有下面两个特点是与ISO9000不同的：

第一、CMM/CMMI的评估是一个持续不断的过程，CMM/CMMI的目的是为了帮助目标企业改进其软件开发过程，而不是简单的认证，因此，每过一段时间就需要进行重新的评估，如果再次评估的时候没有达到上次评估的要求，则在CMM/CMMI的级别发布中会修改其级别。

第二、CMM/CMMI只是对组织中的某一个部门的评估，不会对整个组织/企业进行评估！CMM/CMMI的评估只是针对部门，同时在3级以上才需要组织/企业提供一些环境和配套措施，但它始终都不是对整个组织/企业的评估。

第三、按照规定大概每过半年，该部门的状态就需要进行一次重新的评估，以确保他们在此期间的项目仍然能够达到此前评估中认定的级别。检查该部门是否出现新的问题或者其级别是否已经有所提高！如果过了期限而没有参加评估，则不会被认定仍然具有该资格。在SEI那里记录的也只是曾经通过评估的有哪些，并不是说明现在还拥有资格的有哪些，所以，在看CMM证书的时候一定要注意一下！

因为每次评估，CMM的主任评估师都只会说：

“我是来帮助你们改进过程的。每过一段时间，我们都需要过来评估一下你们目前的开发过程所处的状态，并针对你们的缺陷提出我们的意见和建议，供你们参考来改进你们部门的过程，提高你们的软件开发管理水平……”

 

另外，CMM/CMMI的评估没有其所要求的固定的软件开发与管理要求，它就像一个抽象的理论框架，企业采用哪种具体的实现方法是没有关系的，因此，企业可以选择XP或者选择RUP或者选择其他开发过程来进行这个评估。

 

参考问卷

2． 您所在的公司或项目组采用什么项目过程管理框架？ 

 RUP XP MSF 自定义的过程管理框架 顺其自然，没有采用什么特别的过程管理框架 

 

项目过程管理框架的使用情况与程度表现了一个企业软件开发团队成熟度的最关键的标志之一。从完全混乱的开发状态到现在，中国软件业不到20年的过程中，走过了国外四五十年的经历，调查显示，目前企业中采用轻量级过程XP框架的战友42.5%，重量级软件过程RUP框架的战友17.7%，采用微软MSF框架的有14.6%，而采用自定义过程管理框架的战友20.3%，目前仍然没有采用任何过程管理框架的只有微小的4.9%的比例。

图表 2 开发者公司或项目组对项目过程管理框架的应用状况

 

 

从这些比例数据的对比中可以看出，国内软件企业的规范化程度有了显著的提高，因为软件开发的过程管理框架可以显示出一个企业在软件开发上的规范程度，这是一个企业从混沌状态到规范化状态必须跨越的一个门槛，而有了自己的过程管理框架也说明这个企业有了自己的核心技术人员和专家团队。

关于RUP相关数据的评论：

从软件企业的开发过程和实践来看，完全采用RUP的过程框架进行开发在中国国内是不太现实的，因为RUP过程本身的复杂度和管理上的重量是国内从大型企业到小型企业都无法承受的。这一点也可以从下面使用软件开发辅助工具的情况上看出来。

关于XP相关数据的评论：

而XP的过程由于其先天的特征，要求企业内必须有技术水平绝对高的架构师的存在，而从中国的软件开发历程来看，中国国内目前还没有开发经验20年以上的软件技术人员存在，加上软件技术本身的变革和飞跃，基本上可以认为国内目前还没有真正培养出自己的软件架构师的时间，所以，从这一点来看，完全的XP实施就是不现实的事情，但是部分的采用XP框架进行实施是有其应用环境的。这一点同样可以从后面的第四个问题“您所在的公司或项目组是否选用了迭代的开发方式”中看出来。

 

 参考问卷

3． 您怎样获得需求？（可多选） 

一开始获得所有需求 迭代开发获取需求 现场客户获取需求 其它 

 

需求获取地点上仍然是以客户现场获取需求为主，它占有了48.5%的比例，需求获取的方式上是迭代开发获取为主，它占有超过半数的54.7%的比例，而只有27.1%的开发人员是在项目已开始就获得所有需求的。

图表 3 开发者获取用户需求的方式分布状况

 

需求的获取方式是与当前国内项目和客户的实际状况有着密切关系的，这一点在上图中表现得十分明显。下面我们分为这几个情况进行一下分析：

1、 一开始获得所有需求：

这是瀑布式开发过程所提出的需求获取模式，实际上这对于一般的项目是十分不实用也不太现实的，但是，如果能以这种方式达成需求获取目的，那就是最佳的需求获取时间了。

在目前国内的项目状况上，基本上只有单纯的外包项目才能做到这一点，这个27.1%的数值也可以看出国内外包项目所占的市场分额。比如，东软就从原来最大的国内软件承包商变成了国内相对较大（是不是最大的，还没有看到明确的数据）的外包软件承包商。

2、 现场客户获取需求

现场客户获取需求这不仅仅是国内最常见的需求获取方式，也是国际上几乎所有的软件项目的最初需求获取方式。例外的也只有产品开发类别的项目会不一定需要到用户现场进行需求获取，但是，从一个公司做项目积累到做产品，其实，这个产品型项目的原始需求还是从用户现场获取到的。

至于这个比例只有48.5%的原因，我们认为这应该是由于并不是所有的开发人员都会去做或者去了解需求获取的手段和方式，因此大部分开发人员其实是不需要到用户现场的，尤其是由于人员变动后来进入到项目组中的开发人员是不了解需求获取的最初状态的。

3、 迭代开发获取需求

首先应该认同一点：迭代开发获取需求与现场客户获取需求两者之间是不矛盾的，而且正常来说后者应该与前者的比例是相近的。

迭代开发获取需求一方面是因为国内用户对想要开发的项目的不确定性，这不仅在国内，在国际上也是同样存在的，否则，迭代化开发不会成为目前最流行也最强力的过程论之一。甚至RUP与XP等国际上最著名的开发过程都是以迭代化思想为基础搭建起来的。

迭代开发获取需求并不复杂，其实这也可以看作是原型法的一个展现形式，不断地将已获取的用户需求进行实现，用户在看到已实现的功能的基础上进一步提出自己更深一层的理解和要求。这样不断轮回提升的方式，就是迭代过程的体现。这也符合人类对事物的认识过程，从表象到本质的理解过程，从刚开始的表层理解逐渐过渡到深层次的用户意识目的的理解，从简单的操作电子化到深层次的业务过程重组和整合，然后经过几年的数据积累后再逐渐到专家系统和辅助决策支持系统。

 

参考问卷

4． 您所在的公司或项目组是否选用了迭代的开发方式？ 

 没有采用 没有采用但很想采用  已经采用但不彻底 已经采用并比较彻底 

 

迭代化的思想已经在中国的开发人员中有了很深入的影响，但是，真正懂得如何应用的却并不多。从下表中可以看到，其中46.1%的人士没有采用的，47.5%的人使用的不彻底，采用并且比较彻底的只有6.4%，而部分采用的占有最大的份额47.5%。

图表 4 开发者公司或项目组对迭代开发方式的应用状况

这里可以看到一个中国软件业十分严峻的问题，那就是开发过程中的迭代方法到底是什么，到底如何使用，到底如何应用迭代思想才能帮助我们更好的处理软件开发中遇到的问题。

6.4%的人认为公司使用得很彻底，这一点从一个侧面表现出问题2中的使用RUP和XP的60.3%的人也并不是彻底采用RUP和XP来进行开发的，因为RUP与XP的基础都是迭代化思想，而这里看到的最多只有52.5%的人认为他们公司在使用迭代化思想进行软件开发，这中间差异的7.8%说明了什么？

这两组数据的对比说明国内技术人员对于什么是RUP什么是XP以及什么是迭代还并不能很正确的理解，更不用说，真正的将这些概念能够投入到真实的软件开发过程中来进行应用了。

第2节 软件开发工具的应用状况

n 项目管理工具应用状况

参考问卷

5． 您所在的公司或项目组经常采用下列哪种工具进行项目管理？ 

 Microsoft Project IBM Rational SUMMIT PMOffice primavera Project Planner Artemis Views Microsoft Team Foundation System 其它 

调查显示，现阶段国内在项目管理方面所使用的工具主要是微软的Project，它占有64.7%的比例，虽然Project一直到2002年推出真正实用的企业级项目管理版本，但是由于微软工具使用得便利性上是深得人心的，所以，即使在功能相对较弱的情况下也能够在国内占有较多的用户数量。另外，IBM Rational的Summit占有201%的比例位列第二，其它工具都只占有较少的分额，比如：PMOffice的2.8%，微软的Team Foundation System占有2.4%等等。

图表 5 开发者的公司或项目组采用的项目管理工具分布状况

国内使用项目管理工具除了用它来制定甘特图的计划表之外，还很少有企业用到Project的资源分配，日程管理，进度控制，任务分发等更复杂更高级的功能。

国内企业在项目管理上限于用户需求频繁变更的困境和管理人员的技能水平问题使得他们无法在项目管理上采用有效的计划手段，可以说绝大多数公司仍然处于计划与实际执行的部分脱节甚至完全脱节而无关的状态下。

另外，项目管理的工具有很多种，项目管理较为成熟的企业一般都会考虑根据自己的特点开发一些相关的辅助工具，另外，除了Project等计划管理工具外，常用的工具还有Excel等，很多管理规范的公司都是采用诸如Excel这类的表格工具进行周计划和细节实施计划制定和检查的，而对于Project等工具则是用来指定宏观计划，或者说给领导和客户看的理论执行计划，而这才是计划执行的实质。

参考问卷

6． 在您的工作中，是否会涉及项目管理的工作？ 

 是 否 

调查显示，国内的开发者有76.8%的人的工作内容中涉及到项目管理工作，而只有23.2%的人不涉及到项目管理工作。

图表 6 开发者在工作涉及项目管理工作的状况

从这里我们可以看出国内软件企业的项目管理工作是相当混乱的，单纯从企业项目管理团队的人数比例来看，这个涉及到项目管理工作的比例是何其得高。而由于我们这个行业和网络与计算机的关系，使得我们这个行业的从业人员应该是全员上网，而不是只有管理层才可以方便行使的权力。所以，上面我们看到的数据应该可以认为是全部项目组成员中涉及到项目管理工作的人数居然达到了76.8%，这个数据可以告诉我们，国内的项目管理是何等的混乱，团队的稳定性是何等得差。因为，只有当团队不稳定的时候，才会出现较多的人的工作内容会涉及到项目管理工作，很多软件开发者都经历过刚开始只是一个最初级的编码人员，由于其它人员的离职，他从初级程序员变成高级程序员到整个项目的主程序员，而到了项目结束的时候，已经不得不承担项目经理的角色的实际情况。

而正因为国内企业对员工利益的漠视，这使得软件开发者一年跳槽十多次都成为一种可能。而在一个相对稳定的开发团队中涉及到项目管理的人应该不超过30%，而这样，这个团队才会有足够的技术积累，才能不断地提升团队的整体技术水平，并保证团队的稳定性。而从上面这幅图中，我们不得不为此担心，而这个担心，也是我们对整个中国软件业和软件从业人员的担心。

参考问卷

7． 以下哪些因素是您觉得在选择项目管理工具是最重要的？ 

 品牌形象 简单易用 灵活 功能强大 有良好的技术支持及资源 能提供强大的项目管理咨询服务 其它 

开发者再项目管理工具选择上的考虑首先是简单易用性，它占有了最大的35.0%的比例，其后依次为良好的技术支持及资源17.2%，功能强大14.8%，灵活性12.0%，能提供强大的项目管理咨询服务10.7%和品牌形象9.3%，后面这五个部分基本上没有较大的比例差异。

图表 7 开发者选择项目管理工具所关注的因素

 

从这这个比例差异上我们可以看到，国内开发人员在选择工具的时候主要是考虑简单易用性，其他的因素都是排列其后的，这也是Project占有较大用户数的一个根本原因，而微软产品的简单易用性是他的传统，也是全世界用户对它的最大认可度。

在这里可以看到灵活性其实和简单易用是具有一致性的，，而剩下的除了有良好的技术支持及资源与功能强大这两项要求外，其他的都是比例较小的，微软的Project工具在功能上自2002版发布后，才可以称得上是强大，而微软可以提供良好的技术支持及资源，所以，这也是微软的Project能够占有较大用户数的原因之一。

从只占有10.7%的能提供强大的项目管理咨询服务来看，国内对软件咨询业和从业人员的认同程度也在逐渐的提升，这也许是一些已经对国内老板失望的经验相对较为丰富的技术人员可以考虑的一项未来的职业发展方向。

n 项目需求管理工具应用状况

参考问卷　

8． 您是否亲自做需求管理的工作？ 

 是 否 

需求管理是一个项目过程中必须要做的事情，只有做了需求管理，其管理过程才是真正具有了一定的规范性，因此在CMM2评估中的第一项要求就是需求管理。调研数据表明，国内有59.8%的技术人员亲自参与到需求管理工作中，而不作需求管理的只有40.2%。

图表 8 开发者在工作涉及需求管理工作的状况

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

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

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

参考问卷

9． 您经常采用下列哪种工具管理需求？ 

 Rational RequisitePro Borland CaliberRM Telelogic DOORS Hansky Dragonfly 其它 

在需求管理工作中，需求管理工具的使用就成为一种必然，调查表明：目前需求管理工具在国内企业和开发者中的使用情况是Rational RequisitePro占有48.7%，Borland CaliberRM占有20.6%，而Telelogic Doors占有3.2%，Hansky Dragonfly占有2.2%的比例，而其它部分则占有了25.3%的比例。

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

 

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

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

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

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

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

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

参考问卷

10． 您经常采用下列哪种建模工具？ 

 Visio Rational Rose/XDE Rational Software Architect Together Power Designer ERWin 其它 

软件开发管理工具的覆盖面较大，调查表明：Visio占有41.5%，Rational的Rose/XDE和Software Architect分别为22.6%和10.1%，Power Designer分割了16.1%，其他工具则只占有很小的部分，ERWin为2.2%，而Together只有1.8%。

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

这张图表并不能完全说明问题，这是因为软件开发管理工具的范围太大了，比如说ERWin和Power Designer的核心在于数据库设计，虽然Power Designer也可以作系统架构设计与分析，但是由于历史的原因使得大家往往仅仅会在数据库设计的时候才会考虑到它。而Together、Rational Rose/XDE、Rational Software Architect都属于系统架构设计工具，同时可以关联到需求与代码实现的辅助工具。而Visio只能称之为图形绘制工具，而绝对不能和上面这三个工具相提并论的，适用Visio做流程规划和分析都是可以的，但是，它不能做设计，至少到目前最新的版本为止，它的设计功能都是十分微弱的，这一点连微软顾问服务部的人都承认Visio与Rose不是同一个档次上的工具。

这张图在一定程度上表明了下面几个情况：

1、 数据库建模工具上，现在Power Designer的市场分额远大于ERWin的，而且在平时的开发过程中我们可以看到Power Designer的市场宣传活动也要比ERWin积极很多，我们很少见到关于ERWin的产品宣传与推广。加上Power Designer是一些华人参与开发的，所以，更使得中国人对其有着较深的感情而倾向于使用它。

2、 在设计建模工具上，Rational Rose/XDE仍然占据着较大的市场分额，其后续产品Rational Software Architect也分割了10.1%的市场分额居于第二位，这里可以看到IBM在开发工具方面投入的宣传力度的确产生了实际的效果，这些在与Borland于2003年收购的Together可怜的1.8%的对比中可以看出。加上Borland近年来不断传出的负面效应，尤其是2006年将开发工具部分出售未果最后将之独立成立公司的情况伤害了大批Borlander的心，这种情况到了2007年Together会连这1.8%的分额都很难坚持住，相信在国际市场上也会有同样的负面效应出现。

 

 

参考问卷

11． 您所在的团队中经常采用下列哪种配置管理工具？ 

 Visual Source Safe Rational ClearCase Borland StarTeam Telelogic Synergy Hansky Firefly其它 

配置管理是项目管理中至关重要的一环，即使小到一两个人的团队也要考虑相应的配置管理的问题。调查表明：Visual Source Safe占有52.2%和Rational ClearCase占有的22.8%的比例，位居第一阵营，其他的工具都只有不超过10%的比例，诸如Borland StarTeam的7.6%， Telelogic Synergy的1.8%和Hansky Firefly的1.5%等。

图表 11 开发者团队配置管理工具的种类分布状况

 

配置管理工具上的划分也可以看到微软产品简单易用性的深入人心，当然，它的功能是无法与其他配置管理工具相提并论的，但是，在现阶段，中国国内开发团队在配置管理层面上使用的深度与团队开发规范化程度较弱的情况下，大家对配置管理工具的要求也是相对较低的。这可以从国内很少有大规模的软件项目的投入，甚至很多年都很难听说到这方面的任何消息也是有着很密切的关系的。

ClearCase是一个十分全面功能超级强大的配置管理工具，它甚至可以用于协调几百上千人的开发团队，甚至用于万人以上的团队配合协作也是可能的。可以说从Visual Source Safe6来看，VSS6最多实现了ClearCase百分之一的功能。但是，ClearCase由于功能过于强大，使得其配置和管理上相当复杂，基本上没有经过Rational公司培训过的人是不可能通过自学掌握ClearCase的配置和管理的。当然，一旦配置好了，ClearCase的使用还是十分简单的，开发人员基本上不需要学习就可以直接上手。

Borland的StarTeam也是一款优秀的配置管理工具，但是，由于Borland将开发工具独立出去的行为，将可能使得他的开发工具的市场分额逐渐降低，而StarTeam作为一个非主流配置管理工具而言，加上公司推广力度的减弱，前景更是让人担忧。

对于其它这14.1%的分额而言，其中应该大部分都是CVS或者WinCVS的用户，CVS/WinCVS可以看作是与Rational ClearCase以及Visual Source Safe在国内并列的三大配置管理主流工具了，这一点从下面源代码管理工具上可以获得数据来源的支持。

 

参考问卷

12． 您所在的团队使用下列哪种源代码管理方案？ 

 CVS Visual Source Safe SubVersion SourceGear Vault 个人管理自己的代码 其它 

源代码的管理是软件团队最关注的部分，调查表明：源代码管理工具中Visual Source Safe占有38.3%和CVS占有31.6%的比例并列第一，其他工具的比例较少，例如SubVersion的9.7%和SourceGear Vault的2.1%，另外还有个人管理自己代码的占有10.1%。

图表 12 开发者团队使用源代码管理方案的种类分布状况

 

这张图和前面那张图属于从属关系，因为源代码管理其实是配置管理的一个子项功能，也是配置管理的核心关注点之一，毕竟软件开发最后都要落实到代码上，所有软件项目的结束都是以源代码形成的产品或者源代码自身的交付作为终结点的。

从这张图上CVS占有31.6%的用户分额可以证明问卷11中其它部分的结论。

Visual Source Safe所占有的38.3%的市场分额说明很多公司对Visual Source Safe的安全性还是存在着较大的疑虑，因此并没有像作为配置管理工具那样将源代码也放置到Visual Source Safe中进行统一的管理。而所有的配置管理工具都拥有项目资源管理的功能，因此代码并不是项目的全部，所以才会有这样的比例变化。

从个人管理自己的代码占有10.1%的比例上可以看出下面两点：

1、 国内软件行业开发者有很多仍然处于原始的开发状态下，他们属于个人开发，因此不使用其他的配置管理工具。而这些较为熟练的个人开发者大都有自己的一套代码和文档管理策略，这主要是因为配置管理工具的使用将占用较多的硬盘空间，而对于个人开发者而言，硬盘空间一般都并不是空闲较多的。他们虽然没有采用任何工具来支持这方面的工作，但是个人的代码管理策略还是同样存在的，所以这种现状仍然是不可避免的。

2、 对于企业而言，没有采用代码管理工具来实现，只能说明这些企业在管理上的混乱与无序，这也是中国国内大批中小企业的软件开发现状决定的。这种企业大部分是依靠关系生存的，通过关系拿到一些项目，然后通过招聘刚毕业或者未毕业的大学生作为廉价劳动力来给他们完成这些项目。这种现象在国内已经持续了十多年，相信在目前的情况下，这种情况还会有十多年的存在空间，所以，这种现象仍然是不可避免的。

 

参考问卷

13． 您所在的团队是通过什么工具来进行每日构建？ 

 不进行每日构建 Make脚本 ANT Microsoft BuildIT NANT 其它   

调查表明：国内不进行每日构建的比例未48.2%，而进行每日构建的比例为51.8%中采用Make脚本的是21.3%，采用ANT的是14.4%，采用微软BuildIT的是9.8%，采用其他方式的占有6.3%。

图表 13 开发者团队进行每日构建的工具分布状况

每日构建其实是XP的一项最佳实践，从前面采用XP的42.5%的比例来看，填写软件开发工具问卷的有效问卷只有总问卷数的24.1%，通过这三个比例关系可以看出，国内实际上做每日构建的总比例仍然是十分小的。

而每日构建只有在较好的采用迭代开发的情况下才能做到，因为每日构建是迭代化思想在产品发布、测试与构建上结合的产物。而从前面迭代化开发的比例（完全采用迭代为6.4%，以及在问卷4种的分析）来看，这种采用每日构建的起始时间一般也会都在项目的中后期才可能推行，这和极限编程中提到的项目初始就能够进行每日构建的差别是十分大的，也可以从这里看到中国软件业的规范化道路还是十分漫长的，仍然有很多技术和方法需要我们去学习去积累去实践。

 

参考问卷

14． 您所在的团队中，对集成频度的要求大约是： 

 每月 每周 每天 每小时 

软件团队的集成频度可以从一个很好的侧面看到软件开发团队中团队内部的交流与沟通的频率以及相关技术的应用频度。调查表明，国内开发团队对集成频度的要求主要是每周集成，它占有了超过一半52.6%的比例，每天构建的占有25.2%，每月构建的也有20.1%，而每小时构建的只占有2.1%。

 

图表 14 开发者团队对集成频度的要求分布状况

在实际的软件开发中有很多是由集成的频度可能是相对随意的，这种随意是与项目组团队内的开发进度与用例/用户故事划分有关系的，有可能更多的集成是在3天，4天，6天或者没有较多规律的情况下进行的，而在回答这个问题的时候，很多人都会因为这样而去选择每天或者每周，因为这两者是相对较为接近的。

而每月的集成则是传统的开发方式下，或者重型软件过程模型（诸如RUP）下的常规方式，这里占有20.1%的每月构建可以看到这一点。而这个每小时构建的2.1%与前面的完全采用迭代化开发的6.4%的比例是何其得接近，但是从这里我们可以看到中国软件业规范化的希望。而从52.6%的每周构建和25.2%的每天构建中，我们看到的更多的是担忧和国内软件开发状态的混乱。

参考问卷

15． 您所在的团队常采用下列哪种工具来进行变更管理和缺陷跟踪？ 

 Rational ClearQuest Borland StarTeam Telelogic Synergy Hansky Butterfly Mantis Bugzilla 其它 

调查表明：变更管理和缺陷跟踪工具的使用比例为Rational的ClearQuest占有38.1%，Borland StarTeam为20.1%，其他的诸如Bugzilla的6.6%、Telelogic Synergy的5.6%和Hansky Butterfly的2.5%，同时采用其他工具的还有25.0%的比例。

图表 15 开发者团队对变更管理和缺陷跟踪使用工具的种类分布状况

 

 

变更管理和缺陷跟踪工具的使用一直是国内软件企业和开发团队的弱点，这方面大部分企业都是通过自己的内部调整手段来进行实现的，部分企业和团队将它与需求管理合并起来进行统一的管理，这是因为需求管理主要是针对用户需求变更的管理，而变更管理与缺陷跟踪在一定程度上是和需求管理的表现上是相似的。比如用户使用系统中遇到的问题提出来，这时候需求调研人员要考虑这是需求变更还是系统缺陷，然后进行分类标记，但是一般都是统一登记并进入后续流程的。这张图中占有四分之一分额的其他选项与需求管理中其他的25.3%的比例何其接近，这一点和需求管理中是相似的：“国内有很多公司和团队在使用自己开发的需求管理工具。这是由于需求管理有着明确的起始和终结点，过程相对稳定，有着自己独立完整的工程活动过程，开发难度也较小，所以，很多公司都会根据自己的特点进行同类工具的开发”。

Rational公司在这里仍然占有着较大的用户份额和认可程度，这个原因前面已经陈述多次了，而Borland StarTeam所占有的20.5%的比例也说明Borlander在国内的数量比例还是很大的，但是，如果Borland继续下去，这个份额比例也只能是逐年下降。

诸如Bugzilla的6.6%、Telelogic Synergy的5.6%和Hansky Butterfly的2.5%都说明在这方面的用户认同度是相对较为宽泛的，大家接触的也相对较多，开源工具与商用工具在没有较大规模市场宣传影响的背景上可以做到平分“疆土”的程度。

 

n 开发者对软件生命周期管理工具在功能需求

参考问卷

22． 您认为，新一代的软件生命周期管理工具在功能方面应该首先具有什么特点？ （多选） 

 涵盖软件生命周期的各个环节 强大的团队协作功能 智能化的管理与控制功能 针对特定应用类型进行过优化 针对特定行业应用进行过优化 管理的可跟踪性 安全性 具有企业资源管理功能 增加对开发流程的观测力 其它 

调查表明开发者对软件生命周期管理工具的功能要求可以分为三个层次，第一层为强大的团队协作功能64.4%，涵盖生命周期的各个环节63.7%；管理的可跟踪性52.5%和职能化的管理与控制功能44.3%并列为第二层；第三层包括剩下的五个功能：安全性33.8%，增加对开发流程的观测力31.0%，针对特定行业应用进行过优化28.9%，针对特定应用类型进行过优化23.4%，具有企业资源管理功能21.5%。

图表 16 开发者对软件生命周期管理工具的需求状况

 

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

第一层：

1、 前者说明国内开发者开始逐渐认同团队协作的重要性，而不再过于强调个人能力与个人英雄主义的思想氛围，由于软件开发本身是一种创造性的工作，这也是很多没有机会获得国家或者其他支持进行科学研究的技术人员投身到软件行业的一个至关重要的原因。

2、 后者说明国内开发者已经意识到软件开发本身是需要经历相应的软件生命周期的各个生存环节的，不可能超越或者跨越一些重要的环节直接将代码交付给最终用户。这是与有些极端的极限编程狂者所提出的“代码即文档”的观点的强烈质疑，同样在国外著名的软件工程专家康斯坦丁的《人件集》中也有对“代码即文档”这种观点的直接质疑和反对。

第二层：

1、 说明国内的开发者开始认同软件项目管理的重要性，这也是在十多年的争论和学习以后，国内的开发者终于意识到个人开发与团队开发是两种不同层次的概念，团队开发有着个人开发无法比拟的优势，而团队开发则比个人开发更要求管理，更加强调了管理的重要性；

2、 管理的可跟踪性的超过50%的认同度说明国内的开发者意识到管理是一个循序渐进的过程，它是一个在潜移默化中推动技术进步并在表象上直接推动项目进行的一个因素，管理必须做到可跟踪，否则，这个管理必然是无效的也是混乱的，只有可跟踪的管理才是有序有效的，能够真正对项目的开发产生积极的推动作用。

3、 智能化的管理与控制功能所占有的44.3%的比例，说明国内开发者对这方面的期待和对这个功能的不确定性。要知道软件开发完全是人的行为，属于人的意识层面的活动转变为现实的一个过程，这种管理完全是对人的一种管理，同时对用户思维行为的判断与分析。智能化的管理与控制功能对人的影响是否是客观有效的，这是所有软件从业人员所关注的问题，这也是人工智能技术在沉寂了几年后重新进入软件行业被提出后的一种影响。Ivar Jacobson的公司从2004年起将一些人工智能技术放入到软件工程过程的咨询服务之中，创造了Ivar博士的生动小人形象。这些都是软件从业者在智能化管理和控制方面的尝试与努力。

第三层：

剩下的五项选项主要是在企业层面上的关注，这分别覆盖了下面几个方面：

1、 安全性：也许可以称安全性为软件开发第一话题。

这也是最近几年众多的黑客活动使得大家对软件和网络安全关注的结果，由于软件开发在一定程度上可以做到与外部网络的物理隔离，所以，它所占的比例并不是十分得高，也不是一个首要的问题。

2、 开发流程：增加对开发流程的观测力。

开发过程模型和过程的管理与监督也都获得了开发者的认同。

3、 专业化：针对特定行业应用进行优化和针对特定应用类型进行优化。

这是由于各个行业的特性与差异和应用类别的不同使得专业化成为一个非常重要的话题，甚至有人认为：软件开发方法、软件开发过程等相对较为抽象层次的理论也必须根据各个行业进行实际力举才能让相应行业的开发者认同并愿意采用。这也可以从另一个侧面体现出开发者偷懒取巧的心态和企业管理者不愿意投入资金进行人员培养的心态，大家都想拿现成的，而不是经过自己的研究分析后再使用。

当然，人类历史上的任何发明创造都是为了让人类偷懒！但是，大家都知道工具做得越专业市场范围就会越小，企业产品与行业贴得越紧密随着行业的变化企业的盈亏波动也就会越大甚至因为行业的微小变化就会让企业破产。

这也使很多企业不敢进入过于专业的软件产品方向进行研发的原因，因为在不太久远的软件发展史上大家都看到了很多类似的经典案例。现在连Borland都认为通用开发工具成为一种累赘，是一个不得不被抛弃的鸡肋，那么谁还敢进入更专业的开发工具的研发中呢？这个问题是值得所有软件行业从业人员思考的大问题。

4、 资源管理：具有企业资源管理功能。

这一点说明开发者开始关注团队以外的企业环境和资源，而不是仅仅局限于思考眼前或者身边的一些人和事，如果企业对自己所从事的方向投入不断的减少和降低，或者申请的资源都被拒绝而得不到及时的补充，那么谁都明白：也许自己应该考虑换个环境了。

而从项目管理的角度来看，资源的整合与配置是十分重要的，这一点不需要有任何数据来支持，因为这是显而易见的。试想，一个人完成Windows是多么得不可能，而微软最近在每一个Windows版本开发完成后提供的关于这些人吃掉了多少汉堡、喝掉了多少可乐等等的数据，其实不是在说这些汉堡或者可乐，而是说微软有多少资源在开发Windows的时候被调动起来，通过侧面数据来说明它们的团队协作和公司资源管理与配置方面的优势。

 

第3节 开发者对软件质量管理和测试工具的应用状况

n 开发者对代码质量管理的状况

参考问卷

16． 您经常以怎样的单元测试频率保证代码质量？ 

 每小时 每天 每周 更长时间 不使用单元测试 

这个调查的图表显示国内开发者对单元测试的认可程度和实施状况，而每日40.8%、每周40.2%的单元测试居然合起来达到了81%，每小时进行单元测试的比例只有6.6%，需要更长时间进行单元测试的占有9.6%，而不进行单元测试的也有9.4%的比例。

图表 17 开发者对代码单元测试的频率分布状况

 

 

每小时进行单元测试的比例的6.6%与前面的数据中关于完全采用迭代化开发的比例为6.4%进行一下对比，我们可以看到这两个数据是何其得接近。

由于单元测试是随时进行的，而每周或者更长时间进行单元测试可以认为是单元测试执行的较为粗略或者很难达到实际的效果，对比前面的每小时进行集成的频度比例只有2.1%，而每日的集成频度也只有25.2%，我们也可以看到能够真正把单元测试做到位的开发者和企业比例还是十分少的。

从这个比例上也可以看到国内软件企业与开发者对于测试仍然没有像对开发过程那样重视，甚至有接近10%的企业和人员从来不进行单元测试，这意味着我们的开发者和企业交付给用户的产品中之少有9.4%是几乎没有经过任何测试（如果没有做过单元测试，那么其他级别的测试效果也是可想而知的）就交付给用户的，而且从下面的调查问卷中也可以看到，单元测试是作为代码质量的最主要的保障手段而存在的。

 

参考问卷

17． 您采用了哪些手段来保证代码质量？ 

 单元测试 提高代码覆盖率 代码走查 其它 

代码质量的保障包括上面提到的三个方法：代码走查、单元测试、提高代码覆盖率，此外还有同行评审、编码规范等措施和手段来进行。这里调查数据表明：进行单元测试的有54.0%，采用提高代码覆盖率的有21.9%，进行代码走查的有19.1%。

图表 18 开发者保证代码质量所采取的方法分布状况

而这里单元测试居然有超过一半达到了54%的比例来作为代码质量的保证手段，而从前面的问卷中我们已经得到的结论：目前国内单元测试的执行情况并不理想，甚至是相当得差。在这种情况下，我们如何才能通过单元测试来保证我们的代码质量呢？

其实单元测试是在功能层面上保证代码质量的手段，而在格式、可读性等代码规范化方面代码走查和编码规范都是十分重要的手段，这些手段却没有得到很好的实施。由此可见，我们的代码传承性，也就是代码的可读性和格式都是在开发者和企业并不关注的情况下进行的，这样的代码即使功能上目前达到了要求，又如何保证我们的项目可以有后续版本的持续不断的开发和扩展呢？

软件开发者和开发团队对测试的轻视是自古有之的，这个古是指从最开始有了单独的成品软件出现开始。而且，这个轻视不仅仅在中国有，在国外也是一样的。但是，这种思想在个人英雄主义的时代曾经盛行一时，而当软件进入工业化时代的时候，大家开始逐渐意识到原来的开发状况出来的产品问题较多，于是对应于制造业的品质保障阶段，测试逐渐被重视起来。这个情况我们在后面的几个问卷中还会有更深入的讨论。

 

n 开发者对软件测试的方法和工具

参考问卷

21． 您所在组织由测试团队进行的测试周期有多长？ 

 每月 每周 每天 每小时

从这里可以看到测试周期的长度的比例，从这里可以看到测试的实际效果和企业与团队对测试的重视程度，从这里也可以看到测试人员与开发人员的比例关系。调查表明每月进行软件测试的有24.3%，每周进行测试的占52.3%，每天进行测试的占21.4%，每小时进行测试的只有2.0%。

图表 19 开发者测试团队对软件质量的测试周期分布状况

这里我们对上面的四个条件的比例进行详细分析：

1、每小时都进行测试：

在传统模式下对于国内的企业和开发团队基本上只有进入测试阶段，也就是代码编写基本完成以后才会进行每小时的测试，所以，更多的人会选择时间较长的测试周期。

而每小时进行测试的方式是极限编程中提出来的测试策略，对比前面采用XP的42.5%的比例也可以看到实际上这些XP过程管理框架的应用组织实际上并没有很好的推行XP的核心关键实践。而这个数据比例与迭代思想已经被采用并比较彻底的6.4%（这个比例应该与相关参与者的数据进行同比折算）和系统集成频度为每小时的2.1%以及每小时进行单元测试的6.6%的比例都是十分接近的。

由此可见，国内测试能够将XP中的测试实践做到相对比较好的程度的组织的比例也就只有2%左右。

每小时进行测试的测试人员数量与开发人员数量比例至少是在1:1甚至n:1的状态下才能做到的。

2、每天都进行测试

能够做到每天测试的有21.4%，这个数据说明了国内能够将测试作为软件工程活动的一个重要环节的比例系数，加上每小时进行测试的2%，可以认为国内现在基本上有接近四分之一的组织已经十分重视软件测试活动了。可以认为至少做到每天测试是软件企业和开发团队成熟的标志之一。

每天进行测试的测试人员数量与开发人员数量比例基本上是在1:1到1:3之间的状态下就能做到的。

3、每周才进行测试

每周才进行测试的52.3%说明这些企业或者开发团队所进行的测试不包括单元测试，基本上主要停留在系统测试和集成测试上，也就是说，这些产品并没有考虑代码的有效性问题，而只是从系统的表层进行了检查。这里就好像一个曾经很有名的笑话：外科医生给一个中“箭”的病人治病，只是把表皮上面的“箭”给剪掉的感觉。至于里面是否还有“箭”的剩余部分的残留，测试组是完全不管的。

每周进行测试的测试人员数量与开发人员数量比例基本上是在1:3以下就能做到。

4、每月进行测试

每月进行测试的24.3%的企业可以这样认为，他们根本就没有想过要做测试，甚至领导者会认为测试完全属于浪费时间，浪费资源的做法。他们可能根本就不会考虑团队内存在专职的测试人员。这也说明他们的项目管理完全出于混乱的状态，他们交付的产品也将是没有任何保障的。

同样的问题在下面的调查图表中也可以看到。

参考问卷

20． 您或者您所在的开发团队最常用的测试方式是？ （多选） 

 手工测试 自己编写的测试脚本 采用自动化的测试工具

 

调查数据表明国内进行传统手工测试的仍然是最常用的测试方法，它占有56.0%的比例，而能够进行脚本编写测试的有51.8%，而能够使用自动化测试工具进行测试的只有29.2%。

图表 20 开发者团队采用的软件测试方式的分布状况

上图中的测试方式上的比例让我们对中国软件业的未来产生了更多的担忧，但也看到了一些希望。

占有29.2%的采用自动化的测试工具的比例已经远远高于前几年国内测试行业的状况，这个数据是令我们欣喜的。这也是国内在逐渐形成的对测试重要性的争论中，逐渐走出了一批高水平的测试人员积累的成果。而能够自己动手编写测试脚本进行测试的比例超过了半数，这也说明中国的测试团队已经形成了一定的实力。

但是，上面的三个数据却没有一个能够超过60%，可以说都不占有大多数，对比前面每月进行测试的24.3%的比例，可以看出国内还有40%（这个40%的比例可以从后续的几张图表中得到数据支持）以上的企业和组织根本没有认同测试，他们仍然处在最原始的软件开发状态下生存着。

参考问卷

18． 您或您的团队经常使用的黑盒测试工具是什么？ （多选） 

 不使用自动测试工具 不清楚 Rational Performance Tester Rational Functional Tester Rational Robot MI LoadRunner MI WinRunner CompuWare QARun CompuWare QALoa 其它   

针对黑盒测试的相关调查表明：国内仍有23.8%的开发者及其团队根本不知道什么是黑盒测试，而使用自动化测试工具的占有37.6%，而使用相关自动化测试工具的比例分别是：MI LoadRunner为13.9%，Rational Functional Tester为8.4%，MI WinRunner占7.6%，Rational Robot占6.5%，CompuWare的QARun和QALoa分别占有4.5%和1.1%的比例。

图表 21 开发者及其团队经常使用的黑盒测试工具分布状况

MI LoadRunnner一直在国内的推动力度都是比较大的，在网站上可以经常看到关于LoadRunnner的问题和一些讨论，这方面Rational做得相对较弱，可能因为Rational将自己的核心宣传力量投入到了开发建模工具方面，而没有把测试作为最主要的切入点来考虑。当然Rational的相关测试工具即使在没有很大的宣传力度的情况下，仍然占有相对较高的用户比例，这也和他在开发建模工具方面的影响力是分不开的。

我们可以看到有接近40%的开发者和开发团队没有使用过自动测试工具，这并不是很令人惊讶的事情，但是却有接近四分之一的开发者和开发团队没有听说过自动测试工具，这就很惊人了。没有用过，可能是因为自己周边没有人会使用，或者地域偏僻，或者没有学习到，但没有听说过，这个差别就说明中国国内软件企业和开发者在测试领域缺乏认知程度，同样的比例数在白盒测试上也是存在的。

当然，这也从一定程度上说明，中国大陆还有着广阔的测试技术的发展和推广空间，这也使我们国家的教育业尤其是大学教育和职业教育在软件工程领域需要着重考虑并关注的重要着眼点之一。

 

19． 您或您的团队经常使用的白盒测试工具是什么？ （多选） 

 不使用白盒测试工具 不清楚 Rational Purify Rational Quantify Telelogic LogiScope Macabe Macabe 其它   

针对白盒测试的相关调查表明：国内仍有28.2%的开发者及其团队根本不知道什么是白盒测试，而使用自动化测试工具的占有38.7%，而使用相关自动化测试工具的比例分别是：Rational Purify为21.3%，Rational Quantify为13.6%，Telelogic LogiScope占3.1%，Macabe Macabe占0.8%。

 

图表 22 开发者及其团队经常使用的白盒测试工具分布状况

 

Rational两个工具居然占有了百分之三十左右的比例，这说明白盒测试方面其他公司所开发的工具的确是相对较弱的。白盒测试与黑盒测试不同，其技术难度和复杂度都要比黑盒测试要高很多。可以这样说，有能力开发白盒测试工具的厂商肯定能够推出自己的黑盒测试工具，而相反，则很难。

这里与黑盒测试中有着相似的比例关系，因此就不做更多的赘述了。