软件需求分析中知识转移障碍及应对策略.docVIP

软件需求分析中知识转移障碍及应对策略 　　◆中图分类号：F014.4文献标识码：A 　　内容摘要：本文从知识转移的视角研究软件需求分析，根据von Hippel的问题解决轨迹理论，笔者研究了克服软件需求分析中的知识转移障碍的应对策略。并以案例研究方法，用S省的地税信息化项目展示了迭代、任务分解、非粘性化粘性知识这三项策略如何加速软件需求分析中的业务知识转移。 　　关键词：知识转移 软件需求分析 粘性知识 　　 　　所有软件项目的基本目标都是在规定的时间和预算内开发出高质量的软件以满足客户需求。所以，清楚用户的需求是什么很重要。但在实际的软件项目中明确用户需求却不是一件简单的事。根据美国Standish集团于1994年的调查发现(Leffingwell Widrig, 2002)，给软件项目成功带来挑战的前三项因素包括：缺乏用户参与（占13%），需求和需求规约不完整（占12%），需求和需求规约经常变更（占12%）。由此可以看出，至少有三分之一的开发项目出现问题直接与用户需求相关。这也体现了需求分析是决定软件项目成败的首要因素，值得给予充分重视。 　　本文将需求分析过程视为业务知识由用户方到需求分析人员的知识转移过程。软件需求分析中的知识转移障碍因素主要包括以下三个方面：知识的特征，知识发送者和接收者的特征，以及知识发送者和接收者双方的关系(Joshi Sarker，2003)。本文根据von Hippel (1994)的问题解决轨迹理论探讨如何克服影响需求分析的障碍因素。笔者通过一个成功软件项目――S省的地税信息化项目进行实证性案例研究。笔者将主要探讨以下两个问题：该项目如何克服需求分析中的知识转移障碍；他们所使用的克服知识转移障碍的策略为什么有效。 　　 　　理论基础 　　 　　知识转移是困难的。Arrow (1969)指出社会知识渠道的容量有限，因此，使用社会知识渠道需要付出代价。von Hippel (1994)用“粘性(stickiness)”这一概念来表达信息转移的困难程度，粘性可通过信息转移的增量成本来反映。Szulanski (1996)将粘性用于描述知识转移的困难程度，研究了阻碍企业内最佳实践转移的因素，该研究结果显示，主要的知识转移障碍包括：所转移知识本身的含混性和不可证实性，知识接收方缺乏吸收能力，以及知识源和知识接受者之间的不良关系。von Hippel (1994)和Szulanski (1996)的研究还被应用于营销诀窍和跨国并购中的知识转移问题(Simonin, 1999; Bresman et al., 1999)。Joshi Sarker (2003)首次探讨了阻碍信息系统开发过程中知识转移的因素。该研究根据以前的文献提出了一个影响软件需求分析过程中的知识转移因素的理论框架，该理论框架包括三个主要方面：知识的特征，知识发送者和接收者的特征，以及知识发送者和接收者双方的关系。 　　当进行创新工作需要利用不止一条粘性信息轨迹以解决问题时，问题解决活动的轨迹往往会在这些粘性信息的轨迹间出现迭代。当迭代的成本较高时，那些需要获得存在于多条轨迹上的粘性信息的创新相关问题解决活动有时会被“任务分解”成一些子问题，每一个问题只利用一条轨迹上的粘性信息。当迭代成本较高时，问题解决者将会努力将粘性信息非粘性化或减少某些地点信息的粘性程度(von Hipple, 1994)。在软件需求分析中通常至少要涉及用户和开发项目组两方面的粘性信息，笔者将探讨软件需求分析中的迭代、任务分解和非粘性化努力如何使知识转移成本降低。 　　 　　研究背景与方法 　　 　　本文的研究对象是我国西部一个较大省――S省的地税征管信息化建设项目。该项目于2006年5月8日正式启动核心征管业务需求分析，到2006年7月10日，核心征管业务需求分析完成，并通过S省地税局的评审，签字确认。2006年7月11日到2006年9月9日，完成核心征管业务系统的开发，主要业务模块包括管理服务，申报征收、发票、票证以及数据中心、基金（社保）、会统、违法违章等核心征管业务。2006年9月10日，进行了第一次系统上线试运行，系统运行良好，基本实现了核心征管业务需求，这也标志着项目初步成功。 　　采用案例研究方法是因为笔者的研究问题比较适合通过案例来研究。案例研究尤其适合以下情况，“提出的问题是‘怎样做’、‘为什么这么做’，研究者无法控制事件的发生，以及所研究的问题是现实生活中新出现的现象(Yin, 2003)”。笔者的研究问题完全符合这些标准。主要通过以下方式收集数据。实地观察，笔者通过参加项目需求分析会议和每周项目例会了解项目进展及需求分析过程。在项目正式进入代码编写阶段，本文的作者进入开发现场，随同开发人员一起工作，以发现