ACM通信
ACM通信
IS组织中的案例部署
电脑辅助软件工程(CASE)技术被建议作为一种可能的方法来提高系统开发的生产力和质素[4，6］．虽然一些研究报告称使用CASE可以提高生产率[2，4，6]，其他人则认为预期的生产力提高难以实现[7，9］．研究这些相互矛盾的结果的重要性怎么强调都不为过，因为CASE不均衡的成功已经导致许多信息系统经理推迟实施[8］．
人们提出了许多原因来解释这些不一致。6］．其中最重要的似乎是缺乏使用共同的结果衡量标准[5］．缺乏精心构建的结果度量限制了信息系统管理人员的基准和技术评估工作。Iivari [6]在CASE技术环境中也进行了类似的观察。对技术成果进行有意义的评估需要首先定义业务流程中技术使用的适当度量[3.］．我们提出一个度量框架来评估案例在系统开发中的使用1流程及其组成子流程。
我们进行了一项全国性调查，为我们的研究收集实证数据。使用我们的案例使用评估框架，我们计算了两个度量，采用和灌输，来描述案例在信息系统组织中的传播。我们的分析提供了关于CASE技术采用者和非采用者之间人口统计学差异和相似性的见解。确定CASE最支持和最不支持的开发任务。我们的结果对使用CASE的组织和那些将其作为系统开发的可能规划和设计支持技术进行检查的组织具有意义。研究结果对供应商社区也有重要意义。
评估案例使用的框架
我们利用亨德森和库伯莱德的[5]的资讯系统规划及设计支援技术模型，为我们评估系统发展用例的架构提供参考。他们确定规划和设计支持技术，如CASE，应处理三个关键过程，即系统开发的生产、协调和组织[5］．这些技术的创新应以这些流程为目标，并在每个流程中加以部署。虽然在这些过程中的任何一个过程中使用CASE可以提高效率和效果，但当所有三个过程都得到加强并适当管理它们之间的相互依赖时，可能会获得更大的收益。这里我们讨论这三个过程及其组成子过程。
我们的结果表明，组织只对我们这里考虑的一半以上的开发任务采用了CASE。
CASE支持生产。CASE技术支持生产应该专注于计划或设计决策以及后续工件或产品的积极影响个人或团队的生产能力。生产过程由三个相互关联的子过程组成，即表示、分析和转换。这些子流程依次由许多不同的任务组成。我们在这里提供了系统开发中这些子过程的快速总结:
- 表示任务启用对象、关系或过程的定义、描述或修改。这些任务支持对现象的抽象和概念化。流程流程图、功能图表、实体建模、域集规范和关联或关系映射是CASE技术表示保留表的一部分。
- 分析任务使用户能够探索、模拟或评估对象、关系或过程的替代表示或模型。它们专注于规划和设计的解决问题和决策方面。
- 转换任务通过从本质上替代人工设计人员/计划人员，使重要的计划或设计任务自动化。从经济角度看，这些任务可以替代资本的劳动，本质上强调通过技术投资来提高效率。
CASE支持协调。CASE技术支持协调应该使参与开发过程的多个代理之间能够进行交互。控制和合作被确定为CASE技术应该支持的两个协调过程。控制任务允许用户计划并执行管理或限制团队成员活动的规则、策略或优先级。这些任务包括资源管理和访问控制。合作任务使用户能够与其他个人交换信息，以影响(或影响)团队的概念、过程或产品。这些任务可以作为一种沟通渠道和促进援助。
CASE支持组织。CASE技术支持组织应能够实施政策或程序，以确定生产和协调任务应用的环境。支持和基础设施是CASE技术应该针对的开发过程中组织的两个方面。支持任务帮助个人用户有效地理解和使用技术。这些任务可以提供常见的在线支持。更重要的是，他们可以提供一个媒介来积累和分享其他开发者的经验和学习。基础设施建设任务支持标准的实现，反过来，支持技术、知识、过程或方法在开发项目中跨过程的可移植性，并且可以想象跨项目的可移植性。这些任务还涉及到强制和管理中央存储库的数据定义、存储结构和标准的一致性。
调查的细节
表1展示了用于评估CASE使用情况的框架。它展示了三个开发过程及其子过程，以及我们用来度量CASE使用情况的22个任务。每个任务的CASE使用情况以0到4的范围衡量(0 =完全没有使用;1 =试验用;2 =少数人/项目经常使用;3 =大多数人/项目经常使用;4 =所有人/项目都经常使用)。
我们采用了基于调查的方法来收集研究数据。12名信息系统专业人员，包括高级信息系统管理人员、开发人员和研究人员，评估了我们调查中使用的项目是否抓住了开发任务的本质，以及所提出的测量方法是否适合评估案例在信息系统组织中的使用情况。他们还被要求就向答复者提供的项目措辞和指示的清晰度作出评论。他们的反馈被纳入调查表。
随后，我们进行了一项大规模的全国性调查，因为这使我们能够在美国的IS组织中描述CASE技术的使用(或缺乏使用)性质。限制的、方便的样本更有可能描述有偏见的观点。我们的样本是从计算机高级主管名录美国应用计算机研究公司(Applied Computer Research Inc.， Phoenix, AZ)编制了一份名单，其中包括代表1.5万多个组织的3.4万多名IS高管。该数据库每年更新两次，以保持其流通性。我们的调查连同解释研究目的的求职信被发送给1560名伊斯兰国高管。在第一次邮寄三周后，我们进行了后续邮寄。
共回收350份可用问卷，回复率为23%。在这些受访者中，有245人没有使用CASE，有59人曾考虑使用它，但没有使用，还有46人2使用情况。
测量情况下使用
我们进行了主成分因素分析，然后进行了varimax旋转，以经验地评估在开发的生产、协调和组织方面列出的任务分组。因子分析结果见表2．
生产过程有三个子过程。我们的数据并没有表示和分析两种不同的分组，而是表示一种聚合分组。这可能是因为他们之间有着密切的逻辑关系。有趣的是，转换有两个子过程:开发活动的转换(计划或设计任务的自动化，数据库代码/模式生成，过程代码生成)和验证和增强活动的转换(程序代码的自动重组，程序结构的分析，测试数据的生成)。我们将这些子过程分别标记为“设计和构建”和“测试和验证”。控制和协调子过程作为一个过程出现，表明它们之间的密切关系和缺乏区别。这两个子过程都要求遵守系统开发团队制定的规则，并要求使用通信功能来实现必要的控制并实现所需的合作。正如预期的那样，组织流程有两个子流程，即支持和基础设施。
情况下采用。我们将CASE采用级别定义为使用CASE工具的开发任务的比例达到或超越实验的水平。0分意味着CASE工具没有被用于任何开发任务/项目，而1分意味着CASE工具被用于所有相关的任务/项目。我们为三个过程及其子过程中的每一个计算CASE采用的度量，此外，我们还计算CASE采用的总体度量。
表1展示了一个IS组织，使用表征和分析任务在或超过实验水平。这个组织的表示和分析子过程的CASE采用级别是2/2 = 1.0。我们类似地计算因子分析过程建议的每个子过程的采用水平(表2)．然后，我们通过平均每个流程的底层子流程的采用级别来计算每个流程的采用级别。例如，在生产的情况下，我们首先计算case的表示和分析、设计和构造，以及测试和验证的采用级别。然后，我们对它们的采用度量进行平均，以获得用于生产的CASE采用级别。CASE采用的总度量是通过平均三个过程的采用分数来计算的。我们的采纳措施与过去专注于研究采用复杂资讯科技的研究，包括CASE [8］．
例输液。采用度量将CASE引入IS组织以支持它们的开发任务的比例。然而，任何两个采用CASE来支持开发任务的组织在CASE的使用上都可能不同。一个组织可能在有限的意义上使用CASE，例如在一个试点项目中，而另一个组织可以广泛地在几个或所有开发项目中部署CASE。我们将CASE灌注定义为多大程度上使用哪个CASE来支持开发任务。CASE输液水平计算为CASE所在的开发任务的总使用分数的比率采用3.以及这些任务的最大可能使用得分。
表1显示两个表示和分析任务的CASE使用总分为4 + 3 = 7。使用评分的最大值为2 × 4 = 8。因此，该组织用于表示和分析的CASE灌注水平为7/8 = 0.88。与CASE采用级别一样，我们计算每个生产、协调和组织过程及其子过程的CASE注入级别。此外，我们计算了CASE灌注的总度量。
结果和影响
图1、2和3描述了我们的样本中的组织，并呈现了采用者(N = 304)和非采用者(N = 46)之间的对比。从这些数据中可以得出一些有趣的见解:
- 采用者和非采用者在制造业、政府和服务业这三个行业中几乎有同等的代表性。总的来说，几乎一半的采用者和非采用者组织来自制造业部门，三分之一来自服务业，剩下的是政府组织。行业部门成员不是区分CASE采纳者和非采纳者的变量。
- 在信息系统部门拥有1150名员工的组织占采纳者的比例最高(43.44%)，而那些拥有110名员工的组织占非采纳者的比例最高(43.42%)。随着IS部门规模的扩大，采用者的比例几乎是非采用者的两倍，这与过去的发现是一致的。看起来，较大的信息系统部门更有可能拥有支持案例创新成本的必要资源。
- 根据开发和维护/增强项目的数量评估的投资组合的大小，并没有区分采用者和非采用者。进一步的分析表明，在开发和维护/增强项目的组成方面，采用者和非采用者之间没有区别。
采用和灌输CASE。表3而且图4展示了CASE采用和CASE注入的水平。在采用者组织中，CASE采用的总体级别是中等的。在我们的示例中，采用者的CASE采用率平均水平为0.6，而最大值为1.0。这可以解释为60%的开发任务在某种程度上得到了CASE的支持，而剩下的40%完全没有使用CASE。总的注射水平是0.5，最大的1.0。这个值必须在使用的测量尺度的上下文中进行解释(参见表1；所有人/项目都经常使用0到4。)平均而言，在我们的样本中所代表的IS组织中，很少有人/项目在采用CASE的任务中定期使用CASE。从总体上解释CASE采用和注入水平，我们的结果表明，CASE被用于60%的开发任务，但这些任务中CASE的使用程度仅限于项目的一小部分。
通过比较生产、组织和协调的采用和灌输级别，可以得出一些有趣的见解。所示表4，生产和组织的CASE采用级别大致相同。显著降低的协调采用级别表明组织很少使用CASE功能来支持开发人员之间的协作。同样，与协调任务相比，已通过的生产和组织任务的投入程度更大。
在相对意义上，CASE能力在更大程度上被用于生产和组织目的，而不是用于协调目的。虽然团队工作和团队活动在开发过程中消耗大量资源，但技术支持对团队工作的重要性已被强调[10，这是我们观察到CASE工具最少采用和注入的地方。
采用和灌输CASE生产。用于表示/分析的用例采用级别显著高于设计和构造的观察级别，而设计和构造的观察级别又显著高于测试和验证的观察采用级别(表4)．用于表示/分析和设计和构建的CASE输注水平没有显著差异，但用于测试和验证的CASE输注水平显著低于其他两个子流程。表5显示用于测试和验证任务的CASE使用在与生产相关的任务中排名最低，而用于表示/分析任务的CASE使用不仅在生产过程中排名最高，而且在构成其他两个过程的任务中也是如此。
采用和灌输案例以进行协调。表5总结了每个协调任务的低CASE使用水平。我们示例中的组织在一些项目中使用CASE来执行与系统开发过程活动相关的规则、策略或优先级。然而，CASE在其他协调任务中的使用仅限于实验。可以想象，组织正在倾向于使用专用的、用户友好的工具，例如用于资源管理的Microsoft Project和用于通信的Lotus Notes。我们从我们的研究中得出结论，CASE在协调任务中使用得很少。
为组织采用和灌输CASE。CASE对基础架构的采用和注入水平显著高于观察到的支持水平(表4)．就像用于表示/分析的CASE使用一样，我们发现用于基础设施目的的CASE使用水平已经从实验扩展到在有限数量的项目中制度化使用。然而，CASE仅用于为开发人员提供最低限度的支持(表5)，尽管有效的支持对于减少与吸收复杂技术相关的知识障碍可能至关重要，例如CASE [1］．
结论
过去的研究表明，缺乏使用共同的结果衡量标准是CASE使用和影响报告结果不一致的最重要原因之一。反过来，这可能会阻碍组织使用CASE。在本研究中，我们提出了一个框架来衡量案例在组织中的使用情况。我们通过开发一个框架和一套衡量案例在IS组织中的使用的措施来解决这个问题。我们使用这种方法从IS组织的随机样本中收集数据，并评估这些组织中CASE使用的性质和程度。我们的发现对使用CASE的IS组织和那些将其作为系统开发可能的核心技术进行检查的组织具有意义。研究结果对供应商社区也有重要意义。
当关键功能不仅被采用而且还被注入整个组织时，任何技术的潜力都可以被实现。用户应该认识到，虽然可以从生产、协调和组织过程的个别过程中提高效率和效力中获得收益，但当所有这三个过程都得到改进并妥善管理它们的相互依赖性时，可能会获得更大的收益。我们的结果表明，组织只对我们这里考虑的一半以上的开发任务采用了CASE。此外，他们只在开发项目的一小部分中为这些任务使用CASE。CASE技术没有显示出对系统开发性能的很大影响，或者没有广泛接受该技术的合理影响，这并不奇怪。
具体地说，CASE功能在更大程度上被用于生产和组织目的，而不是用于协调目的。然而，团队工作和团队活动在开发过程中消耗了大量的资源。技术支持对团队合作的重要性再怎么强调也不为过。然而，我们发现CASE工具的采用和注入最少。用户和供应商都需要认识到CASE技术在这方面的采用率和输入率非常低。
一般来说，CASE的使用率低于输液。这在总体发展水平上是正确的，对于生产、协调和组织的组成过程也是如此。这并不奇怪，因为开始使用技术比广泛地将其吸收到组织工作系统中要容易得多。事实上，注入一项复杂的技术，如CASE，可能不仅需要修改它以适应组织的需要，而且需要对组织的做法和程序进行大量修改，以培养一个有利于增加使用它的环境。这样的修改虽然困难，但并非不可能实现。对推广CASE的使用感兴趣的组织应该仔细评估他们的组织系统、程序和管理实践可能会如何限制技术的内部推广。
我们希望引起对两个特定领域的关注，在这两个领域，CASE的采用和注入水平特别低。在考虑的生产子流程中，用于测试和验证目的的CASE的采用和注入程度是最低的。这些任务是乏味的，但是CASE似乎并不是帮助开发人员执行这些任务的首选技术。此外，CASE仅用于为开发人员提供支持。供应商应该检查用CASE工具打包的支持在减少知识障碍和增加CASE使用方面发挥的作用(如果有的话)的程度。这些障碍是需要克服的关键障碍，以便实现更高层次的采用和灌注复杂技术，如CASE。
参考文献
1.技术扩散和组织学习:商业计算的案例。组织科学3， 1(1992)， 119。
2.集成计算机辅助软件工程中的重用和生产率:一项实证研究。MIS季度15， 3(1991年9月)，375401。
3.Delone, W.H.和McLean, E.R.信息系统的成功:对因变量的追求。资讯系统研究三， 1(1992年3月)，6095。
4.Finlay, P.N.和Mitchell, A.C.对引入CASE的好处的看法:一项实证研究。MIS季度18， 4(1994年12月)，353370。
5.I/S规划和设计辅助工具的维度:CASE技术的功能模型。资讯系统研究(一)， 3(1990)， 227254。
6.为什么CASE工具没有被使用?Commun。ACM 39， 10(1996年10月)，94103。
7.CASE工具作为组织变化:调查系统开发中的增量和根本变化。MIS问:17， 3(1993年9月)，309340。
8.Rai, A.和Patnayakuni, R.N.案例采纳行为的结构模型。j .管理。信息。系统。13， 2(1996年秋季)，205234。
9.Vessey, I.， Jarvenpaa, s.l.和Tractinsky, N.评估供应商产品:CASE工具作为方法论伙伴。Commun。ACM 35， 4(1992年4月)，90105。
10.Vessey, I.和Sravanapudi, A.P. CASE工具作为协作支持技术。Commun。ACM 38， 1(1995年1月)8395。
数据
图1。按行业划分的组织分布(条形图上的数字表示样本中各类别组织的数量)。
图2。按ISD规模划分的组织分布(条形数字表示样本内各类别组织的数目)。
©2000 acm 0002-0782/00/0100 $5.00
允许制作本作品的全部或部分的数字或硬拷贝用于个人或课堂使用，但前提是该拷贝不是为了盈利或商业利益而制作或分发，并且该拷贝在第一页上带有本通知和完整引用。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，需要事先获得特定的许可和/或付费。
数字图书馆是由计算机协会出版的。版权所有©2002 ACM有限公司
没有发现记录