【转】寻求一种更好的软件工程研究方法

Mary Shaw

寻求一种更好的软件工程研究方法

Mary
Shaw

School of Computer Science, Carnegie Mellon University

摘要关于对物理学,生物学和医学的研究过程,人们早已有了公开的精准的解释。即便是在形式上看似简单,但这个领域的内和外也算提供了有价值的“高水准研究”的指导。但是软件工程就不同了,人们至今尚未明确找到并解释如何研究以及用何种方法去进行研究??。(方法论也是顶层设计,只有找到了高屋建瓴的研究方法,才能推动这个行业的进步。本论文发表于2002年,经过多年的努力,人们(包括Mary
Shaw在内的有识之士),已经找到了一些研究方法,软件工程取得了长足的进步。所以软件业已经得到了突飞猛进的发展,它对社会变革和发展起到了举足轻重的作用。---译者注)

在科学与工程研究领域描述了根据他们发现的有价值的调查,适合他们的研究方法,和他们评估结果采用的标准。我也为软件工程都勾勒出一个轮廓,以展示他们的
想法成熟度在转变中研究策略和方法中的差异性。了解这些战略能够清楚地帮助软件工程师们的设计研究计划和报告结果;它也有助于详细地解释软件工程研究在计
算机科学和其他科学家的特征。(软件工程学科与其他工程类的学科一样,是生产(或开发)软件系统的基础,如
果没有软件工程专业知识,软件系统就会搞得乱七八糟,难道不是吗?中国目前的状况就是这样。所以Mary
Shaw们通过大量的调查研究,寻找合适的研究方法,制定恰如其分的评估标准,为软件系统的开发寻求一条光明之路。现在看来,这条道路已经慢慢明朗了,不
论的由DOD委托CMU制定的CMM,还是微软,IBM等自己制定的软件开发内部标准都是行之有效的。当然还有更多的先后出台的关于软件工程教育方面一整
套教育教学标准等---译者注)

1、引言

许多学科对它们的研究策略有很好的解释。这些解释包括不仅给研究人员有详细的指导,而且也有简约方式给到公众和其他观察人员。接受其结果依赖于获取结果的
过程,以及分析的结果本身。小学生做物理的实验模型:有假设,对照实验,分析和可能的反驳。公众了解大规模双盲医疗研究足以讨论实验治疗的风险,从对照组
预提治疗伦理和利益冲突,被致盲的过程解决了。

软件工程不会有这种很好理解的分类指导。软件工程研究人员很少有人会写明确的关于他们研究的范式以及他们评判质量结果的标准。曾经有过一些表征着软件工程
研究的尝试,但他们始终没有勾勒出一幅对软件工程全面理解的关系图来。1980年,我曾考察了工程学科基于工艺和技术的关系,并制定为软件制定了一个工程
学科的预期计划。1984至1985,Redwine,Riddle,和其他人一起从研究思路到广泛的实践提出了一个软件工程技术发展的模型。最近,软件
工程研究人员在报告中曾批评这个领域中常见的实践,在收集,分析和报告实验度量的缺陷。在2001年我提出了一些软件工程研究的成功范例,从软件体系结构
中绘制了大量的例子的草图在科学的和工程的研究领域,可以通过以下的特征来识别他们的价值:
• 
什么样的问题是“有兴趣”的?
•  什么样的结果有助于回答这些问题,和什么样的研究方法可以产生这些结果?
•  什么样的证据可以证明结果的有效性,以及如何有良好的效果来区分优劣?
  
在本文中,我试图通过在软件工程领域中普遍可以接受的研究策略,以确定哪些研究是在实践中被广泛接受的。。(寻找一套如何解决软件开发过程中行之有效的策略,研究人员首先从学校课堂上通过工程类的思想出发,积极探究软件开发过程中特点,逐步形成软件工程的全面的关系图。---译者注)

1.1、软件技术日趋成熟
    
Redwine和Riddle验证了一些软件技术,看看它们是如何发展和繁衍的。他们发现,软件技术从概念制定到推广的准备通常需要15-20年的发展。他们确定了六个典型阶段:

• 
基础研究 审视基本思路和理念,从初始结构上寻找问题,研究软件框架重要的问题。

• 
概念形成
从非正式想法,发展成一个研究团体,聚集一组兼容的想法,发布具体的子解决方案。

• 
发展和延伸 
初步使用的技术,明确基本思路,概括的方法。

• 
内部提升和探索 
扩展到另一个领域方法,使用技术的实际问题,稳定技术,开发培训材料,显示在结果中的价值。

• 
外部增强和探索 
类似的内部,但涉及更广泛的社区的人但他们不是开发者,展示大量证据的价值和适用性。

• 
推而广之 开发生产,确保质量,版本的技术支持,商业化和市场技术,扩大的用户群体。

Redwine和Riddle罗列出20世纪80年代中期几个软件技术进展阶段的时间表。我也提出了一个20世纪90年代成熟的软件体系结构类似的分析。

这里,我们的兴趣是在最初的3个阶段,即研究阶段。软件工程研究的目的是帮助提高软件开发的实践性,因此研究计划应规定过渡。 Redwine
-
Riddle数据表明,花费约15-20年中的10年用来进化概念成型与发展和推广(更多的时间都用在基础研究,但它是非常困难的,以确定这一阶段的开始)。因此,充分了解研究战略必须考虑到随着时间的推移积累的证据,以及个别项目和论文的形式和内容。

   
影响项目
提供了从研究到实践路径的跟踪轨迹。该项目的目的包括识别所做贡献的类型,所起到实质性影响和成功研究的类型。目前正在会议上讨论了初步取得结果。

1.2、软件工程及相关研究前期的反思

关于软件工程的研究,但不限于此,包括对实验的研究。此外,它类似于在某些方面,比如像在人机交互的研究。

W. F. Tichy

Professor of Computer
Science, Karlsruhe Institute of
Technology
Software
engineering
 - parallelism - empirical software
engineering
 - configuration
management
 - software
architecture

1.2.1、对实验性软件工程的批判

在1993年,Basili提出了软件工程实验研究范式的方法。后来,Tichy和他的同事在会议论文报告中批评了缺乏定量验证的实验:“计算机科学家们很少发表有实验验证结果的论文,。。。论文低比率有验证结果似乎是计算机科学研究的一个严重的弱点。这种弱点必须纠正。”

根据论文的贡献程度,他们在计算机科学分类出246篇论文进行比较,其他两个学科的有147篇论文。大多数的论文(259/403)都是提及设计和建模的
结果。然而,他们确定每一篇论文它的结果评定,基于文章文字的一小部分对评估的贡献。他们发现,例如,在所有样本中假设检验是罕见的,很大一部分
(43%)计算机科学的设计和建模论文,而没有任何实验的评估,比一般计算机科学,软件工程样品就更糟了。

Marvin V
Zelkowitz        
Delores
Wallace                   Victor
R. Basili

ZelkowitzWallace架构了关于Basili实验范式的描述并评估了600篇计算机科学论文,和从其他学科出版超过10年时间的100余篇论文。他们同样发现,过多篇论文没有实验的验证或仅是非正式的实验验证,虽然他们也注意到在他们的研究中所涵盖的10年期间取得了一些进展。

以这些批评为前提,软件工程研究应遵循经典的实验范式。下面是笔者探索一个不同的问题:软件工程研究在这个领域中如何认识高质量的特点是什么?(大
量文献表明,从已有的计算机科学,或软件工程学科的论文缺少实验性的内容,定性的内容较多,而定量的成分少些。这可能与专业或学科特点有关,软件系统可以
有模型,当然模型的种类随着软件技术的发展和进化也发生多次变化;而开发的过程很难用实质性的指标,因为都是跟人打交道的,关于人员的量化,工作量化,以
及进度等方面量化,虽然有些量化指标,但是如果与其它工程类相比较,相差许多。---译者注)

Willian Newman

Consultant, Professional Speaker,
Writer, and Author - Mr. Newman brings over 25 years of experience
in strategy and IT planning across multiple industry sectors. He is
a Certified Management Consultant (CMC) since 1995 and has led
consulting practices at several tier-1 strategy firms and global
systems integrators. He is a former executive of Volkswagen of
America‘s IT division.

1.2.2、用摘要预估的方法来研究分析

在工程的研究方面,Newman通过人机交互(HCI)的方式进行比较性研究。他认为工程的特点就是实践,确定了三种主要类型的研究成果,并在5个工程领域进行了初步调查并提出研究报告。他发现,超过90%的贡献是三种:


增强型建模分析技术,基于相关理论,可以用来判断设计方案是否可行,或预测性能是否可行;


增强型解决方案,克服不相溶性方面的问题,或者说是更容易与现有的模拟技术分析;


增强型工具和方法,应用分析模型和在建构功能的模型或原型。

Newman创建了用摘要预评估的方法 - 风格化的模板摘要都会捕获到论文的本质 –
每一篇论文对这些类型的贡献。例如,摘要预评估方法为增强的建模技术是“现有<模型类型>模型在处理<求解策略>是<特
性>上是有缺乏的。一种增强型<模型-类型>的描述,能够提供更准确的分析/预测的设计在<求解策略>的<特
性>。

模型进行了测试,通过比较分析/预测与经验的<特性>测量值。“他发现,以占可比部分的HCI文学,他需要两个以上的范本,为“激进的解决方案”,“经验和/或启发式”。

据纽曼报告,除了能帮助你识别一份论文确定是什么样的研究报告以外,同时摘要评估方法还帮你注意力集中阅读论文。这似乎是合理的假设,如果作者是典型的论
文类型更加自觉地意识到,他们会发现它更容易写论文,介绍了他们的结果和证据清楚。通过摘要评估方法文件特征的方法也可用于软件工程,但更有表现力的描述
性模型(如下文所述)提供了更好的匹配文件。

Frederick P.Brooks,Jr.
Pro.Frederick P.Brooks,Jr.曾荣获美国计算机领域最具声望的图灵奖(A.M.TURING
AWARD)桂冠。美国计算机协会(ACM)称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。

1.2.3、开阔的研究视野

Brooks的报告显示了人机交互之间分歧(tension)的研究


“狭隘的真理,证明了令人信服的可靠的统计实验,并


广泛的“真理”,普遍的适用,但仅支持可能不具代表性的意见”。

前者满足科学的黄金标准,但很少,相比设计师们每天的决定而言较狭隘。后者提供了务实的指导,但可能有过度概况的风险。

布鲁克斯建议,通过确定性壳的结构以纾缓紧张- 认识到三个嵌套类的结果:

•   
结果:信誉卓著的科学真理,真实性和严谨性的判断;

•   
观察:报告实际现象,趣味性的判断;
•   
经验法则:由作者签署的概括,但可能不完全支持的,判断与作为标准的所有三个新鲜有用的数据。

这种紧张是真正的软件工程中人机交互的关系。

当发现出现问题的时候,观察和经验法则提供了宝贵的意见和实践指导。他们还有助于理解和领域的研究奠定了基础,时间,产生的调查结果。

2、软件工程中的问题,结果和验证
   
一般来说,软件工程研究人员寻求更好的方式来开发和评估软件。他们的动机来源于实际问题,研究的主要目标往往是软件产品的质量,成本和时效性。

本节提出了一个模型,解释了软件工程的研究论文的研究,他们所问的问题,所产生结果的类型,以及他们所提供的验证特征类型的分类。这种模式已经发展了好几
年。这是一份完善的版本,是一份我基于2001年ICSE,2002年ICSE会议,经研究生课堂和提出摘要的多次讨论结晶。它的状态是,在布鲁克斯的意
义上说,一组观察,或许成为了一种概括。

2.1、研究问题的类型

研究问题可能是有关的软件开发方法,关于方法的分析软件,有关的具体制度的设计,评估,实施,约概括整个系统类,或纯粹的可行性的任务。表1显示了研究问题的类型的软件工程师要求,再加上一些例子,具体的典型问题。

在ICSE提交的论文中,最常见的论文类型是一种软件开发的一个改善方法或手段。另外比较常见的论文是关于方法进行分析,主要分析的正确性(测试和验
证)。回顾软件工程过去的历史,有一些迹象表明,因为该领域日趋成熟,问题的类型也在改变。例如,一般化,特别是在更正式的模型的形式上,变得越来越普
遍,随着该领域的日趋成熟,可行性论文似乎变得不那么常见。

表1
软件工程研究的问题


问题的类型


实例


分析方法或手段


我们该如何生成/创建(或自动)这个X?

有什么更好的方式生成/创建这个X?


分析方法


我如何评估X软件的质量/正确性?
我该如何在X和Y之间做出选择?


设计,评估或分析的特定实例


什么是X应用程序(更好的)设计或实施?

Y的什么工艺品/方法是X的属性?
X如何与Y比较?
X的什么当前状态/实践Y?


一般性与特殊性


给出X,Y(一定)是什么?
究竟是什么,我们的意思是X?
X有哪些重要特点?
对于X而言,什么是一个很好的正式/经验模型?
什么是X,它如何相连?


可行性


如果x存在,是什么样子的?
是否有可能完成X?

2.2 研究结果的类型

研究产生新知识。这种知识是一种特殊的结果的表达形式。这个结果可能是一种特殊的程序或软件开发或软件分析的技术。从更广泛的意义上来说,捕捉一种模型上
一定数量的特殊结果;这种模型在精度上和格式上产生许多层级。有时,这种结果能解决一个特殊的问题或克服一种特殊的分析。最后,根据Brooks调查,观
察和经验法则,可能是很好的初步结果。表二列出了这些类型,收集了一些特殊典型问题举例。

到目前为止,最常见的一种ICSE论文报告了一个新的程序或软件开发或分析技术。它可以描述叙述,或它可以具体表达一个工具。分析性模型和描述性模型也很
常见,分析模型的支持预测分析,而描述性模型解释问题区域的结构或暴露重要的设计决策。经验模型不可能产生良好的统计数据备份。

表二、软件工程中的研究结果


问题类型


举例


程序或技术


新的或更好的方法完成一些任务,如设计,实施,测试,评价,选择中的取舍,包括操作技术实施,表达,管理和分析,但不建议或指引


经验模型


基于观察数据的经验模型


分析模型


结构模型精确到足以支持正式分析或自动操作


符号或工具


正式的语言以支持实施技术或模式(应该有一个微积分,语义,或其他基础计算或推理)的工具,它体现了一种技术


具体的解决方案


解决应用问题,演示了如何使用软件工程的原则
-
可能是设计,而不是实现一个系统或运行系统的发展体现了结果的仔细分析,它可能是载体的结果,或它的实施可以说明一个原则可以适用于其他地方


回答或判断


具体分析,评估,或比较结果


报告


有趣的观察,经验法则

2.3、研究验证的类型
   
良好的研究不仅要有好的结果,而且结果也应该是明确的和证据的令人信服的。这种证据,应是根据经验或系统的分析,而不是简单的有说服力的论据或课本上的例子。表3显示了一些常见类型的验证,验证在实践中并不总是很清楚和令人信服的。

Table 3.
Validation techniques in software engineering


验证的类型


举例


分析


我分析我的结果,并通过正常分析)找到满意的严格推导和证明(经验模型)控制使用精心设计的统计实验(控制)实验数据


经验


我的研究结果用到真实的案例中去,可被其他人用得比我还多,验证它的正确性/有用/有效性的证据是…定性模型)…
叙述(经验模型,数据,通常的统计在实践中

(符号,工具)比较类似的结果在技术,实际用途


举例


下面是一个例子,它是如何工作
(玩具为例)的玩具,也许是出于现实
(生活片)......我一直在开发一个系统。


评估


鉴于标准的规定,我的结果...
(描述性模型)...充分描述的现象(定性模型)占感兴趣的现象...
(经验模型)是能够预测......因为......,或使结果符合实际的数据...
包括可行性研究,试点项目


劝导


我想很难过这个问题,我相信...
(技术)...如果你做了下面的方法,...
(系统)构成的系统像这样...
(模型),这种模式似乎是合理的
需要注意的是,如果原来的问题是,一个工作系统的可行性,甚至不加分析,可以有说服力的


公然断言


没有严重的尝试评估结果

 

3、对策研究

本文第二小节罗列出了以报告形式在代表性会议上或期刊论文中个人研究结果的三个重要方面。很显然,良好的科学研究策略范围包括计算机科学意义上的实验,它
也同样清晰地勾勒出更广泛意义上的关于对实验的研究。当然,它不包含对所有问题,结果,和验证的组合的理解。检查表1-3显示了有意义的组合。持续报告所
接受的策略,而不是设定一个规定的标准,在本节中,我观察和评论了出现在一些文献中报告的模式。

3.1、创建研究对策

在软件工程中最常见的研究策略,常常是通过想出一个新的过程(步骤)或技术分析或讨论它使用和验证的案例;在实际应用中使用案例是引人注目的莫过于使用理想化问题的例子,解决了某些软件开发方面的问题。

另一种常见的研究策略提供了一种分析方法来分析一些软件开发方面,往往是正式的,模型并验证,通过其使用的正式分析或它的经验。

表4显示了策略,有40篇研究论文收录在ICSE2002年的摘要。有些论文是不包括在内,因为策略从摘要看不是明确。
   
这些描述符合纽曼的预览摘要。这些模板识别兼容的问题,结果,验证集。例如,第1.2.2节中所引述的“增强模式”对应的泛化或特性的问题回答的分析或实
证(或精确的描述)模型,通过实证分析或控制的实验验证。通过几种选择打包在一起,命名的集合,纽曼清楚地标识选定的策略。然而,尝试将其应用到软件工程
文献中发现缺点的覆盖面。

3.2、从优秀论文中建立良好的结果

我们这里讨论的主意集中在个人会议报告和期刊论文的结果中。然而,随着时间的推移,取得的主要成果连续获得的可信度的结果逐步得到改善,进一步增强了可信度。评估软件工程结果的重要性应该在大背景下进行。

随着进展情况出现的增长,他们提供了保证持续投资于研究会得到回报。因此,在某个领域的初次报告中提交的探索性研究的有说服力的案例可以是非正式的和定性
的,而后期递交的报告中要验证大规模的投资后,要有经验和要有正式模型。这种增长模式符合Redwine-Riddle所提出的技术成熟模式。这里提出的
模型不解决这个累积建立信任。

表4中。 ICSE2002年的基础上提交的摘要的研究策略


问题


结果


确认


计数


开发方法


程序


分析


3


开发方法


程序


经验


4


开发方法


程序


案例


7


开发方法


定性模型


经验


2


开发方法


定性模型


说服


1


开发方法


分析模型


经验


3


开发方法


符号或工具


分析


1


开发方法


符号或工具


经验


1


开发方法


符号或工具


案例


2


分析方法


程序


分析


1


分析方法


程序


经验


3


分析方法


程序


案例


2


分析方法


分析模型


经验


1


分析方法


分析模型


案例


1


分析方法


分析模型


案例


2


分析方法


工具


分析


1


实例评估


特性分析


分析


3


实例评估


特性分析


案例


1


实例评估


答复


分析


1

4、小结

软件工程得益于对研究策略更好的理解,取得了极大的成功。这里提出的模型反映了这个学科的特征:它识别出了引起软件工程师感兴趣问题的类型,我们产生回答这些问题结果的类型,这些迹象类型表明我们使用的评估结果。

我们所研究的问题有不同的类型,所研究的策略也有各不相同的反应。一个研究项目的策略应选择一个结果,一种方法以获得一个成果,以验证策略适合于问题的研究。这些选择更明确的认识可能帮助软件工程师设计研究项目,并报告其结果,它也可以帮助读者阅读和评价文献。

当一个领域日趋成熟,问题也会随兴趣而发生变化。有迹象表明成熟的想法会发生转变,从对定性和经验的理解,到准确和定量模型。

这种分析注重个人的研究报告,但影响实践的重大成果,依靠积累的许多项目的证据。因此,每个单独的论文提供知识增量,集合相关课题的研究和报告,同时提供确认和累积的证据。

致谢

这些思想的开发得益于来自与卡耐基 -
梅隆大学的同事们的讨论中,在开公的FSE会议上讨论,以及2002年的ICSE会议。这项工作还得到了在卡耐基梅隆大学工作的A. J.
Perlis 主席的支持。(20130410)

转载自: http://blog.sina.com.cn/s/blog_553f35510101bjou.html

时间: 2024-10-07 17:27:35

【转】寻求一种更好的软件工程研究方法的相关文章

阿里在使用一种更灵活的软件集成发布模式

当今典型的软件集成发布模式是,通过类似GitHub的Pull Request或GitLab的MergeRequest的方式管理特性分支(Feature Branch):在通过代码评审等方法确认一条特性分支上的改动没问题后,将其合入集成用的分支.随后,代码改动进入在集成分支上运行的持续交付流水线,直到发布上线. 在阿里巴巴内部,尽管这种工作方式也得到了研发协同工具平台(Aone,对外叫云效)的支持,但广大研发同学选择的主流工作方式却不是它,而是用一种被称之为变更(全称变更请求,英文Change R

在 .NET中,一种更方便操作配置项的方法

在应用程序的开发过程中,我们往往会为软件提供一些配置项,以允许软件根据配置项灵活来做事情,比如配置日志文件路径等,此外,我们还可以用配置项来为用户存储其偏好设置等. .NET 为我们默认提供了配置机制以及配置文件,项目中的 app.config 或者 web.config 文件(如果没有,可以添加)就是 .NET 为我们提供的配置文件.在这个配置文件中的根节点 configuration 下,创建 appSettings 节点,在此节点中,我们可以添加自义定的配置项.同时,Configurati

[ZZ]39条更好的软件开发方法

1.重构是程序员的主力技能. 2.工作日志能提升脑容量. 3.先用profiler调查,才有脸谈优化. 4.注释贵精不贵多.杜绝大姨妈般的“例注”.漫山遍野的碎碎念注释,实际就是背景噪音. 5.普通程序员+google=超级程序员. 6.单元测试总是合算的. 7.不要先写框架再写实现.最好反过来,从原型中提炼框架. 8.代码结构清晰,其它问题都不算事儿. 9.好的项目作风硬派,一键测试,一键发布,一键部署; 烂的项目生性猥琐,口口相传,不立文字,神神秘秘. 10.编码不要畏惧变化,要拥抱变化.

一种脱离VC编程软件的方法学习C/C++编程(搭建EditPlus实现在文本编辑框中执行.c文件

网上下载一个EditPlus记事本安装好后就可以按照下面步骤进行搭建环境了: 一.工具(Tools)→配置用户工具(Configure UserTools...),[添加工具](Add Tool>>)→[应用程序](Program)1.[菜单文字](Menu text)随意书写(此处写“编译”):2.[命令](Command)代表要执行的程序,写gcc.exe可执行文件全路径(F:gccbingcc.exe): 3.[参数](Argument)是传递给gcc的命令行参数“$(FileName)

你的以太网速度足够快吗?四种更快的速度正在路上&amp;#183;&amp;#183;&amp;#183;&amp;#183;&amp;#183;&amp;#183;

以太网的未来将远远超越下一个最快速度:为无处不在的网络协议绘制路径的网络project师们正在寻找新版本号来服务于各种应用程序. 在上周六的以太网联盟(一个行业组织,用于促进IEEE以太网标准)会议上,三大新项目被提出来讨论.为了x满足数据云中心的迫切需求,确立了25Gbps(字节/秒)的以太网速率标准.但鉴于未来几年内数据云的迅猛发展,专家已经在商讨50Gbps的速率标准了.对于那些新的.高速Wi-Fi接入的企业来说.立即就要实现2.5Gbps的以太网速率.除此之外,未来的最高时速主要将被应用

基于spark排序的一种更廉价的实现方案-附基于spark的性能测试

排序可以说是很多日志系统的硬指标(如按照时间逆序排序),如果一个大数据系统不能进行排序,基本上是这个系统属于不可用状态,排序算得上是大数据系统的一个"刚需",无论大数据采用的是hadoop,还是spark,还是impala,hive,总之排序是必不可少的,排序的性能测试也是必不可少的. 有着计算奥运会之称的Sort Benchmark全球排序每年都会举行一次,每年巨头都会在排序上进行巨大的投入,可见排序速度的高低有多么重要!但是对于大多数企业来说,动辄上亿的硬件投入,实在划不来.甚至远

在Ubuntu 12.04 中如何更换一个更快的软件源?

在ubuntu 下下载安装软件使用不同的镜像源速度差异非常大, 官方的那个比较慢,所以选择最快的最有效率.设置方法不一,网上教程比较常见的是自己手动去更改更新源列表,把特定版本的源列表直接复制到 /etc/apt/sources.list 文件中,但是有时候源文件会失效,而且不一定每次源文件都是跟自己的版本兼容的. 网上看到一个教程,方法很简单, 转载一下:(转自于IMCN) 在Ubuntu 12.04 中用户如何更换一个更快的软件源?

iis System.Data.OracleClient 需要 Oracle 客户端软件 8.1.7 或更高版本。”解决方法

今天事情特别多, 电话不断, 但事情得一件一件的做. 在用VSTS2005/2008+Oracle9做环境连接Oracle时候,在VS 开发服务器运行正常,但IIS服务器调试和部署会报错! IIS服务器报错:System.Data.OracleClient 需要 Oracle 客户端软件 8.1.7 或更高版本. 出错的原因: 1.虽然报的是需要安装客户端8.1.7及以上版本,实际是.net账户没有访问Oracle\bin文件夹的权限 2.在 Windows Server 2003/2008 的

专车将成一种”更贵”的“出租车

日前,交通部对外发布了<网络预约出租汽车经营服务管理暂行办法>(征求意见稿)."办法"首次将"专车"这种出租车运营形式分类为互联网预约出租车,并允许其与传统出租车一样,在中国境内合法运营. 办法首次对网络预约出租车进行了定义,并对想要从事网络预约出租车的企业,从事网络预约出租车的车辆和驾驶员进行了条件限制. <网络预约出租汽车经营服务管理暂行办法>(征求意见稿)对网络预约出租车的定义如下:"本办法所称网络预约出租汽车经营服务,是指以