【IT168 分析评论】
IT开发技术人员作为信息化技术的使用者、应用的规划者和实施者是中国信息化建设的中坚力量。2006年年末，我们开展了一次调研活动。
通过对软件开发过程技术应用的研究，以及对比在研究中所涉及的调查数据，可以看出国内软件企业的规范化程度正在不断提升，在开发过程中对软件开发辅助工具的使用也日益普及，但是，中国软件企业仍然有大部分处于原始开发状态，需要真正懂得软件工程技术和管理的技术人员、国内软件咨询技术企业的自我完善和成长。
中国的软件行业从上世纪八十年代末开始形成，到现在已经经历了将近二十年的时间，这二十年时间里，国际软件行业和技术的革新变化非常之大，我们不得不面对国际软件行业企业已经走过了几十年的历程和经验积累对我们产生的压力。
从下面的调查数据上我们可以看到中国软件行业的从业人员的努力与拼搏，但是，仍然有太多的地方是不如意的，也使得我们中国软件行业的从业人员不得不再次的深入思考，反省我们曾经的做法，规划我们将来的道路。
一组组的数据上到底说明了些什么问题，下面我们会在文中进行详细的分析和讲述。
本文中主要针对中国软件项目开发管理体系的建立状况进行调查、分析。
1、开发者公司或项目获得软件评估认证体系的分布状况
图表：开发者公司或项目获得软件评估认证体系的分布状况
ISO9000被认为是国内各种类型的企业在规范化进行中必须经过的一种认证，CMM/CMMI评估是2000年开始进入中国大陆并迅速得到各类软件企业认同的一种评估手段。
可以这样说，基本上通过CMM/CMMI评估的软件企业都会先考虑通过ISO9000系列的认证，因为CMM/CMMI评估的费用较大，周期也相应较长。
通过ISO9000是国内软件公司取得规范化的第一条路，并且是必经之路。从上图的调查数据可以看出，只通过ISO-9000系列认证的接近40%，通过ISO-9000认证和CMM/CMMI评估的接近30%。这样，通过ISO-9000系列认证的软件公司应当超过50%。CMM/CMMI评估体系虽然与ISO-9000认证不同，但是取得CMM/CMMI评估是一些软件公司在取得ISO-9000认证之后，更深一步的目标追求。
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的过程框架进行开发在中国国内是不太现实的，因为RUP过程本身的复杂度和管理上的重量是国内从大型企业到小型企业都无法承受的。这一点也可以从下面使用软件开发辅助工具的情况上看出来。
而XP的过程由于其先天的特征，要求企业内必须有技术水平绝对高的架构师的存在，而从中国的软件开发历程来看，中国国内目前还没有开发经验20年以上的软件技术人员存在，加上软件技术本身的变革和飞跃，基本上可以认为国内目前还没有真正培养出自己的软件架构师的时间，所以，从这一点来看，完全的XP实施就是不现实的事情。
这一点同样可以从后面的 “您所在的公司或项目组是否选用了迭代的开发方式”的调查数据中看出来。
3、开发者获取用户需求的方式分布状况
图表 ：开发者获取用户需求的方式分布状况
需求的获取方式是与当前国内项目和客户的实际状况有着密切关系的，这一点在上图中表现得十分明显。下面我们针对这几个情况进行一下分析：
对于一开始获得所有需求，这是瀑布式开发过程所提出的需求获取模式，实际上这对于一般的项目是十分不实用也不太现实的，但是，如果能以这种方式达成需求获取目的，那就是非常好的的需求获取时间了。所以，有接近三成（27.1%）的开发者采用这种方式。
从目前国内的项目状况来看，基本上只有单纯的外包项目才能做到这一点。这个27.1%的数值也可以看出国内外包项目所占的市场分额。比如，东软就从原来最大的国内软件承包商变成了国内相对较大的外包软件承包商。
对于现场客户获取需求，这不仅仅是国内最常见的需求获取方式，也是国际上几乎所有的软件项目的最初需求获取方式。例外的也只有产品开发类别的项目会不一定需要到用户现场进行需求获取，但是，从一个公司做项目积累到做产品，归根结底，这个产品型项目的原始需求还是从用户现场获取到的。至于这个比例只有48.5%的原因，我们认为这应该是由于并不是所有的开发人员都会去做或者去了解需求获取的手段和方式，因此大部分开发人员其实是不需要到用户现场的，尤其是由于人员变动后来进入到项目组中的开发人员是不了解需求获取的最初状态的。
对于迭代开发获取需求，首先应该认同的是迭代开发获取需求与现场客户获取需求两者之间是不矛盾的，而且正常来说后者应该与前者的比例是相近的。迭代开发获取需求一方面是因为国内用户对想要开发的项目的不确定性。这不仅在国内，在国际上也是同样存在的，否则，迭代化开发不会成为目前最流行也最强力的过程论之一。甚至RUP与XP等国际上最著名的开发过程都是以迭代化思想为基础搭建起来的。
迭代开发获取需求并不复杂，其实这也可以看作是原型法的一个展现形式，不断地将以获取的用户需求进行实现，用户在看到以实现的功能的基础上进一步提出自己更深一层的理解和要求。这样不断轮回的方式，就是迭代过程的体现。这也符合人类对事物的认识过程，从表象到本质的理解过程，从刚开始的表层理解逐渐过渡到深层次的用户意识目的的理解，从简单的操作电子化到深层次的业务过程重组和整合，然后经过几年的数据积累后再逐渐到专家系统和辅助决策支持系统。
4、开发者公司或项目组对迭代开发方式的应用状况
图表：开发者公司或项目组对迭代开发方式的应用状况
从上面的数据分布可以看到一个中国软件业存在的十分严峻的问题，那就是开发过程中的迭代方法到底是什么，到底如何使用，到底如何应用迭代思想才能帮助我们更好的处理软件开发中遇到的问题。
其中46.1%的人士没有采用的，47.5%的人使用的不彻底，只有很少的6.4%的人认为公司使用得很彻底，这一点从一个侧面表现出公司/项目组使用RUP和XP的60.3%的人的认识是有问题的，因为RUP与XP的基础都是迭代化思想，而这里看到的最多只有52.5%的人认为他们公司在使用迭代化思想进行软件开发，这中间差异的7.8%说明了什么？
这两组数据的对比说明国内技术人员对于什么是RUP、什么是XP以及什么是迭代还并不能很正确的理解，更不用说真正的将这些概念能够投入到真实的软件开发过程中来进行应用了。
