这篇文字是应目前在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%的比例，这一方面说明中国的软件开发者不得不在各个阶段来面对需求变更的问题，另一方面说明软件开发过程中的需求管理工作仍然相对处于混乱状态，并不是专人负责，职责明确的分工合作，中国软件业的规范化还有相当长的道路需要走。
用户业务需求变化的频繁程度可以从这里也可以看到，只有当用户需求频繁变化的时候，软件开发者才会因为需要应对需求的变化而不得不与需求管理工作打交道，这也使得软件开发者认为自己都在亲自做需求管理。而当需求相对较为稳定的情况下，软件开发者所面对的需求变更次数不是频繁到必须每一个业务模块的开发者都必须进行多次的需求变更工作，那么软件开发者就不会都认为自己是亲自在做需求管理工作，因为将这项工作转交给指定的需求管理员也是一种更高效更规范化的操作方式，同时也会减轻自己在开发过程中受到外在影响而不得不改变工作频率导致工作效率降低的一种有效措施。