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

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

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

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

    而XP的过程由于其先天的特征，要求企业内必须有技术水平绝对高的架构师的存在，而从中国的软件开发历程来看，中国国内目前还没有开发经验20年以上的软件技术人员存在，加上软件技术本身的变革和飞跃，基本上可以认为国内目前还没有真正培养出自己的软件架构师的时间，所以，从这一点来看，完全的XP实施就是不现实的事情。

    这一点同样可以从后面的 “您所在的公司或项目组是否选用了迭代的开发方式”的调查数据中看出来。

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

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

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

    对于一开始获得所有需求，这是瀑布式开发过程所提出的需求获取模式，实际上这对于一般的项目是十分不实用也不太现实的，但是，如果能以这种方式达成需求获取目的，那就是非常好的的需求获取时间了。所以，有接近三成（27.1%）的开发者采用这种方式。

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

    对于现场客户获取需求，这不仅仅是国内最常见的需求获取方式，也是国际上几乎所有的软件项目的最初需求获取方式。例外的也只有产品开发类别的项目会不一定需要到用户现场进行需求获取，但是，从一个公司做项目积累到做产品，归根结底，这个产品型项目的原始需求还是从用户现场获取到的。至于这个比例只有48.5%的原因，我们认为这应该是由于并不是所有的开发人员都会去做或者去了解需求获取的手段和方式，因此大部分开发人员其实是不需要到用户现场的，尤其是由于人员变动后来进入到项目组中的开发人员是不了解需求获取的最初状态的。

    对于迭代开发获取需求，首先应该认同的是迭代开发获取需求与现场客户获取需求两者之间是不矛盾的，而且正常来说后者应该与前者的比例是相近的。迭代开发获取需求一方面是因为国内用户对想要开发的项目的不确定性。这不仅在国内，在国际上也是同样存在的，否则，迭代化开发不会成为目前最流行也最强力的过程论之一。甚至RUP与XP等国际上最著名的开发过程都是以迭代化思想为基础搭建起来的。

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