科学网 › 标签 › 软件开发

标签: 软件开发

相关帖子	版块	作者	回复/查看	最后发表

没有相关内容

相关日志

[转载]IDE: baiyunrui 2012-1-16 16:42; IDE环境一般指的是集成开发环境，是指用于网站、软件开发的平台。常见的IDE有： Zend Studio 、 PHPEclipse 、 Komodo 、 PHP Designer 、 PhpED 、 Eclipse 、 NetBeans 、 IntelliJ 、 Visual Studio; 个人分类: 编程开发|0 个评论

[转载]软件开发中的形式化方法（郑红军张乃孝）: gaohj 2011-12-10 21:29; http://lunarxuan.bokee.com/diaryIndex.b 软件开发中的形式化方法郑红军张乃孝（北京大学计算机科学技术系，北京 100871）摘要本文基于研究的角度，首先讨论了在软件开发过程各阶段使用形式化方法的可能及困难，进而研究了形式化方法在理论上和应用上的能力、局限性及其产生原因，以及由此产生的对形式化方法的讨论。最后，综合上述讨论，从形式化方法的实质出发，在方法上，对形式化方法的研究提出了几点建议，以及基于这些建议所能看到的形式化方2法研究可能的一些发展方向。关键词形式化方法软件开发 *本文受到国家自然科学基金项目和863-306 项目资助 1 形式化方法随着软件系统复杂度的不断增长，开发正确、可靠的软件，成为一个急待解决的问题。解决此问题的一个有前途、有希望的技术是形式化方法的应用。形式化方法建立在严格的数学基础上，其目标是希望能使系统具有较高的可信度和正确性，并能使系统具有良好的结构，使其易维护，关键是能较好地满足用户需求。 “形式化方法”一词虽然一直被广泛地应用，但在不同程度上，因理解不同，使其具有了不同的含义。一般说来，形式化方法是指具有坚实数学基础的方法，它是数学上的综合、分析技术的应用，用于开发计算机控制的系统，经常有推理工具的支持，它可提供一个用于模型设计和分析的一个严格而有效的途径。从形式系统和复杂问题的本质来看，还未有一个适于全面描述和分析一个复杂系统的形式系统。所以，可以说，一个“形式化方法”并不是系统设计者开发系统时可能选择使用的方法，而只是设计者在此过程中希望利用的一种工具之一。总体上，形式化方法大致可分为五类：（1）基于模型的方法 — 给出系统（程序）状态和状态变换操作的显式但亦是抽象的定义，但对于并发没有显式的表示，如：Z 和VDM 。（2）代数方法 — 通过联系不同操作间的行为关系而给出操作的隐式定义，而不定义状态，同样，它亦未给出并发的显式表示，如：OBJ、CLEAR。（3）过程代数方法 — 给出并发过程的一个显式模型，并通过过程间允许的可观察的通讯上的限制（约束）来表示行为，如：CSP、CCS。（4）基于逻辑的方法 — 有很多方法采用逻辑来描述系统的特性，包括程序行为的低级规范和系统时间行为的规范，如：时态逻辑。（5）基于网络的方法 — 根据网络中的数据流显式地给出系统的并发模型，包括数据在网中从一个结点流向另一个结点的条件。如：Petri 网、谓词变换网。在形式化方法的使用中，这些方法之间的区别并不总是那么清楚的，有些是结合多种方法的多个方面而形成的混成（hybrid）方法，大多数方法都以集合论和谓词逻辑作为其根本基础，所以，这些方法在技术上都有一些相似性。不过，在表达能力上，这些方法之间有着一定的不同，这也是上述分类的主要依据。形式化方法可以两种不同的方式来使用。首先，它们可用于生成规范，然后将此规范作为传统系统开发的基础；第二，形式规范以上述方式产生，然后将其作为验证程序正确性的依据。在第一种情况，数学将被作为生成规范的主要工具。形式化规范的好处在于：精确、抽象、简明和可操纵。操作可以包括规范的一致性检查、原型的自动生成或通过证明的方法推导出规范的一些特殊性质。在第二种情况，具有与第一种情况类似的益处，除此之外，还可以利用形式化方法证明规范及其相应程序的正确性，以表明程序与其规范的一致性，这样，可以使软件开发有可能具有与数学证明同样的确定性。虽然形式化方法在研究和应用上都取得了很大的进展，也越来越成为研究者和软件开发者感兴趣的方法，但在理论上和方法上（哲学上）仍有其自身的局限性，而且有关使用形式化方法开发大型软件系统和解决特殊问题的适用性及其适用程度问题还不很清楚。本文基于研究的角度，首先讨论了在软件开发过程各阶段使用形式化方法的可能及困难，进而研究了形式化方法在理论上和应用上的能力、局限性及其产生原因，以及由此产生的对形式化方法的讨论。最后，综合上述讨论，从形式化方法的实质出发，在方法上，对形式化方法的研究提出了几点建议，以及基于这些建议所能看到的形式化方法研究可能的一些发展方向。希望本文能有益于形式化方法的研究和应用，也希望有助于认清形式化方法的能力、局限性及适用性，以使形式化方法能更有效地发挥其内在的潜力，从而能够使形式化方法成为解决软件开发问题的有效途径之一。 2 形式化方法在软件开发过程中的应用 2.1 软件生命周期软件生命周期涉及从初始概念到软件产品，以及产品的使用和维护阶段的软件开发过程。为讨论方便，我们采用生命周期的一个一般模型，此模型将软件开发的生命周期分为五个阶段：（ 1 ）需求规范 — 描述系统及其操作环境，特别强调系统与环境间的接口。（ 2 ）系统规范 — 描述系统输入、输出以及它们之间的关系。系统规范是待开发系统的外部特性描述，不涉及系统的内部结构。（ 3 ）详细设计 — 描述用于实现此系统的算法及数据结构。（ 4 ）实现 — 程序源代码，规范的一种可实现映象。下面，我们将分别讨论在上述五个阶段使用形式化方法的可能及其困难。 2.2 需求分析需求分析是软件开发过程的第一阶段，它将用户的需求从初始概念转换为需求文档，需求分析的结果应描述系统及其操作环境，而且还应能描述不可计算的系统，需求文档是与用户交流思想的主要基础。然而，极少有专门面向需求的形式化方法。在需求阶段使用形式化方法将会更加完善形式化方法已知的益处，如：非二义性、完全性、一致性等，这样，形式化方法中的符号系统将会变得更全面、更完整，它不仅能描述功能性的需求，而且亦能描述非功能性的需求。但是，形式化方法中的符号系统还未将表达能力和直觉结合起来。使得符号系统对用户是可表达的（可接受的），同时又不失去形式化方法所特有的精确性，形式化方法距此还有很大的差距。 2.3 系统规范系统规范仍是属于需求范围。这一阶段主要描述系统而不涉及环境，它给出系统接口的精确定义，主要涉及系统应做什么 (WHAT) ，而不是如何做 (HOW) 的问题。这对于使用代数规范技术非常有利，它采用输入、输出间的关系来描述系统的行为。在此阶段，可以应用两种可能的形式技术：一个是发展代数技术以使其可应用于大型系统的规范（尚未见到代数规范应用于大型系统中的实例），这就要求此技术能将规范模块化；另一个是可能在技术上找到一条可以减少设计自由度的途径。 2.4 体系结构设计体系结构设计阶段描述系统的接口、功能、结构的初步实现。体系结构这一概念更接近于面向模型的规范和过程代数。但面向模型的规范缺乏结构性。在此阶段应用形式化方法的主要问题是，没有能够完成需求阶段所有工作的方法或符号系统。目前，形式化方法的使用者必须选择适合其应用领域特点的方法，或使用一种折衷的方法，从不同的形式化方法中找到一个合适的方法来完成此阶段的工作。 2.5 详细设计详细设计是由体系结构规范出发的精化过程。许多形式化方法都支持“精化” 这一概念。精化可以使我们定义和验证同一系统的两个描述之间关系的正确性、一致性。详细设计中的保持结构观点与目前的精化技术是一致的，传统的精化技术主要应用于顺序系统，也有一些技术支持并发系统，如： CCS 。就我们所知，目前尚未有可以同时支持并发和顺序方式的令人满意的形式化精化机制。从实用角度讲，为使形式化方法能够应用于详细设计和精化过程，有必要采用一种折衷的方法，基于一种特殊的基础，研究如何将各种形式的 (Formal and Informal) 规范联系起来。 2.6 实现在此阶段，已有大量的关于形式处理的工作，即：将一程序与其的规范形式地对应起来。这一技术即是所谓的构造方法，构造方法基于从低级规范推导出程序这一想法，将程序构造与验证统一起来，验证环境是基于与构造技术类似的数学基础，但它主要关心程序和规范之间的自动 / 辅助正确性证明。形式实现技术在顺序程序上应用较广，目前也有对并发程序方面的研究。这一技术的使用代价很高，所以主要用于高精确系统的开发，因为高精确系统中的一个很小的错误可能会引起极大的灾难。若要使形式实现技术能广泛地应用，还须对其做较大的改进，以提高其效率，降低其使用代价。 3 形式化方法的能力及其局限性 3.1 形式化方法的能力我们首先从理论上讨论形式化方法的能力。规范是用于软件开发者与用户相互交流的主要媒体，它就象一种混合方言，虽然形式化方法使用者具有不同的背景，但他们都将也应该以同一种方式来解释它，这正是用于交流之语言所必备的条件。所以，一个交流媒体应该是清晰的，并且是无二义性的。规范的清晰和无二义性并不等于说它是精确、抽象或简明的，但规范的这五个性质是相互关联的。下面我们讨论一下这五个方面的关系，从中可以看出形式化方法的能力。二义性问题，相对来讲还是比较容易处理的。形式符号系统具有一定的数学性质，所以它们非二义性的基础在于其内在的数学结构。越是复杂的数学概念，越是建立在更原始的概念之上，如：集合、命题逻辑。这就是说，形式符号系统可以具有合适的解释，并在理论上足以确保规范的一致性解释。形式规范是由一些精确的定义组成的，因为其符号系统的含义是明确定义的。若将英语作为交流媒体，将很难得到精确的规范，对于其他符号系统，如：结构化方法所使用的符号系统，虽然也是精确的，但其只对结构性具有较强的表达能力，而对功能性则表达能力较弱。所以，使用形式化方法，能够得到比其他规范方法更精确的规范。精确规范的直接益处在于：它能减少规范中的二义性和误解释的可能性（危险）。精确是形式化方法或形式符号系统的一个特征，是产生无二义性规范的主要依据。另外，形式规范主要的语用益处在于：可以对形式规范进行较详细的构造性检查，因为对此规范中的具体内容的含义不会有争议，有争议的只是内容的完备性。换句话说，精确有助于确认和交流。由于适当的形式机制的使用，使得规范的抽象性成为可能。抽象是人们处理复杂性的主要智力工具之一，而且通过忽视不感兴趣的部分，从而有助于清晰性。各种形式符号系统对于精确、抽象地表达概念具有各自不同的能力，但它们均可用于严密地描述概念，更重要的是，它们比自然语言的描述更严密、更精确、更抽象。规范的抽象、精确及简明性都有助于使规范更清晰，当然，良好的结构也有助于清晰性。在理论上，至于为什么形式化方法不能产生良好的结构还不清楚，但这似乎并不是形式化所固有的。一般地，形式系统（框架）使得表示一个规范与其相应程序之间的映射成为可能。前面曾提到形式规范的一个很有价值的特性：可操纵性。这就是说，可以在明确定义的规则的指导下，分析规范或或对形式规范进行变换。利用形式规范的可操纵性可以证明规范的一致性；可以推导出关于此规范的一些重要结果；还可以验证规范的实现过程，至少可以验证源代码相对于其规范的正确性。更一般地说，有可能将不同级别规范间的验证以及规范与程序间的验证问题简化为形式证明问题。这样，形式化方法就可以提供程序对应其规范的非常高的可信度。所以，可操纵性也有助于确认，并且由这种特性可以得到进一步的抽象（推导出的性质），同样，也有助于使得规范更清晰。形式化方法在理论上的这些能力，使得它在应用上也具有一定的实力。现在从形式化方法应用的角度，简要地讨论一下形式化方法的上述能力在其应用中的表现。总的说来，在某种程度上，形式化方法的上述能力在其应用中均有体现。一般来说，比较、分析各种不同软件开发方法的有效性是很困难的。形式化方法作为一种交流的形式，也许是最有效的形式。因为它很容易在规范上取得一致，也易于形成文档。虽然非二义性、清晰性等特性并不是形式化方法的全部实质，但它的确为用户与设计者提供了一个有效的交流方式，这一点可以从形式化方法应用于实际的软件开发中可以看出来。形式化方法在实际软件开发中的使用并不是非常广泛，但在其应用范围内，其效果还是可喜的。IBM 的Hursley 曾经发表通过在CICS 中使用Z，使其开发费用降低了9%，同时在错误率上也有很大的、可观的改进，虽然所开发软件的形式规范部分只占一小部分。由此可以看出，形式化方法的使用对于改进软件的质量是非常重要的。不过，对于形式化方法在实际工业项目的应用，相对的就比较少了，形式化方法在安全系统软件上的应用实例更少。然而，值得庆幸的是，虽然形式化方法在实际应用中有一定的局限性，但上面讨论的形式化方法的能力在实际系统中都有具体的体现。虽然如此，形式化方法仍有其局限性，在理论上，最大的局限性大概要与二义性问题有关。在实际应用中，最大的问题与可操纵性有关，大部分是因为有效工具的缺乏所造成的。下面，我们将详细讨论这两个问题。 3.2 形式化方法的局限性事实上，现有的形式化方法并不能完全与上面所述的理想情况一致，在很大程度上与目前方法及其支持工具的研究及开发状态有关，当然也有其他因素的影响。当前的形式化方法有许多弱点和局限性，毫无疑问，这在形式化方法的实际应用中也都有具体的表现。形式化方法之最基本的弱点或局限性与规范确认问题有关。我们可根据“数学的必然性”由规范开始开发软件，但将总是怀疑初始规范的真实性（精确性）。显然，如果能够消除这种疑虑是极其有价值的，但证据表明，软件错误的主要来源正是规范。这就意味着，规范所使用的数学工具并不能足以保证规范的“安全” 性。更宏观地讲，我们面临着一个权衡问题，就是要在投入形式开发的力量与投入研究验证高阶规范方法中的力量之间权衡。需要注意的是，可以使用证明技术来辅助确认过程，如：通过由一个规范推导出其安全特性，但这只能简单地缩短形式化与现实世界之间的距离，而并不能消除它。所以，我们不能简单地依赖于形式化机制以取得证明规范的安全性。第二个主要的局限性与规范的解释有关。对于形式规范，在其数学基础意义下，并不是只有一种解释。软件工程师可以根据计算模型解释；系统用户可以根据系统操作环境中的系统使用模型来解释。这样，二义性问题已不是形式规范在其内部逻辑中存在唯一模型的问题，而是不同领域、不同背景和知识下的各种解释的相容性问题。形式规范的确是比其他相对松散的规范二义性问题要少，但这并不能说明在其多种解释下不可能存在二义性问题，这就削弱了形式化方法的能力，但我们并不能因此而否定它。形式化方法的一个基本问题是，所谓的非功能性需求和性质的规范在目前的形式化方法中很难规范清楚。为了能将形式规范与现实世界联系起来，也为了对规范的解释给以指导，可以对规范中的基本实体和其他基本概念给出较松散的描述。在处理规范时，大部分仍以形式化方法处理，在特殊情况下（非功能性描述）可以采用非形式化方法处理。这样，对于二义性和精确问题，形式化方法的真正局限性在于形式化方法只能减少对规范误解释和错误的机会，而不能消除它们。这就要求形式化方法的使用者应正确地看待形式规范，应认识到，形式规范的目的是增加其可信度，减少软件开发中的错误，但形式规范并不能完全保证其可信及无错误。形式规范的可信度在于对软件产品及其开发过程的理解，如果形式证明具有与形式规范同样高的效率，那么，以形式化方法开发出的产品的复杂度将是可观的。易言之，证明本身是非常复杂的并且亦难以理解。这就导致一个问题：形式证明的使用是能够提高还是降低对一个软件系统的理解度和可信度呢？这个问题是相当难回答的，因为在回答过程中，很难不受到当前程序验证工具的能力问题的影响。对于一个规范或程序，至少其停机问题是不可判定的，因此也就无法形式地证明其是否停机。虽然象这类不可判定问题在实际中并不常见，但形式化方法使用者必须认识到，在形式系统中，有一些问题即使是简单的，也是无法证明的。认识到这一点，对形式化方法的应用相当重要。形式化方法中，形式规范起着一定的关键作用，但规范的使用者不易接受规范的形式化和规范中极难理解的名词、概念。象Z 和CCS 符号系统中所体现出的数学抽象，使得规范能够简洁和精确，但这类符号系统却对规范的清晰性没有多大好处。有许多人认为，清晰性和精确性是有其对立性的，其主要原因是，在实际应用中，我们过分地依赖于规范的非形式解释，而不是根据其内在逻辑来解释它们，以更好地理解规范之含义。一个与之相关的问题是，形式规范技术往往会有许多基本的数学背景，而这些背景又往往与实际问题没有直接关系。事实上，形式规范并不是真正的精确，因为关于形式化方法的符号系统和语义并未能定义的令人满意，就是Z 也有很多版本，虽然现在在IFIP 的努力下，得到一个Z 的标准。当前的形式方法的研究与发展并不象理想情况那样好，尤其在协调形式化方法的表达能力、灵活性与定义的精确性之间的关系上有一定的困难。另外一个主要问题是我们对工具及其应用应相信到什么程度。关键问题是对于复杂工具应相信到什么程度，尤其是那些比实际问题还复杂得多的工具。事实上，我们使用的编译器和定理证明器都要比实际应用程序复杂得多。因此，有必要对工具进行测试或证明，但这又产生了一个递归问题：对用于验证验证工具得的工具，我们应相信到什么程度呢？所以，形式化方法及其支持工具只是减少了开发的风险，如：通过规范的一致性检查，但它并未消除所有的风险，而且还可能引入了风险，尤其是在依赖和使用工具这一问题上。最后，关于形式化方法的教育和训练问题亦是形式化方法中的主要问题。当然，如果软件开发者愿意接受教育和训练，那么，这一问题是易解决的，但情况并非象想象的那么理想。 4 关于形式化方法的讨论正是由上面讨论的形式化方法的局限性，形式化方法的反对者对形式化方法提出了一些质疑。虽然有些意见是片面的，例如，在形式化方法的表达能力与支持工具的能力方面的质疑，但这些反对意见无疑是有益于形式化方法的研究与广泛的应用的。值得一提的是，上面提到的关于形式化方法的理论问题也影响着实际系统的开发，尽管早在1976 年Gerhart 和Yelowitz 提出了形式验证程序的失败之处，但其问题的原因在于其证明过程的不适当，而不是证明本身有问题。许多反对者认为形式化方法及技术在本质上就是错误的，它不适于软件开发过程。另外一个问题是，我们认识到的形式化方法的局限性对其应用有多大的影响？我们认为，形式化方法的局限性并不影响形式规范本身作为交流和文档工具的价值，而验证、精化问题是一个实质性的问题，我们需要用其他方法来丰富精化的证明，并不是形式化方法本身有什么错误。现在并没有一个充分的精化技术完全支持形式化方法，这一点仍是一个很难的研究课题。形式化方法是有争议的，其支持者认为形式化方法是对软件开发的一场革命，而其反对者则认为形式化方法不可能有多大的发展。因为大多数人对形式化方法并不是很熟悉，所以就很难断定哪一方是正确的，于是就造成了对形式化方法的一些误解和误用。以其研究和应用形式化方法的事实分析了当时对形式化方法认识的七个误区：（1）形式化方法能够保证软件是完全正确的。事实是，形式化方法也是能够出错的。（2）形式化方法的全部即是程序证明。事实是，形式化方法的全部是规范。（3）形式化方法只适用于safety-critical 系统。事实是，形式规范有助于任何系统。（4）形式化方法要求具有很高的数学基础。事实是，规范所需的数学是简单、容易的。（5）形式化方法增加了开发的费用。事实是，从长远的观点来看，形式规范可以降低开发的费用。（6）形式化方法对用户来说是不可接受的。事实是，形式规范可以帮助用户理解软件系统。（7）形式化方法未能应用于真正的大型软件的开发中。事实是，形式化方法每天都应用于工业项目中。最后Hall 提出，虽然形式化方法不是“万灵药”，但它是一个有力的工具。 Hall 还针对上述七个误区，给出了形式化方法对的七点认识。随着形式化方法的不断研究和发展，对形式化方法亦有了更新的认识，同时也在软件开发界产生了对形式化方法认识的新的误区。根据其使用形式化方法的切身经验及对形式化方法更深入的研究，又给出了另外七个误区，并以事实解释了误区的形成原因，及误区的错误所在。这七个误区分别是：（8）形式化方法延误开发过程。（9）形式化方法缺乏工具。（10）形式化方法代替了传统的工程设计方法。（11）形式化方法只能应用于软件。（12）形式化方法是不必要的。（13）形式化方法并没有被支持。（14）形式化方法的使用者总是使用形式化方法。其结论与基本相同，即形式化方法并不是“万灵药”，而只是一种用于改进系统可靠性的方法之一。对于形式化方法批评最激进的是对形式化方法几乎持完全否定态度的。他对形式化方法以讽刺的口吻提出了四点质疑。我们认为，无论是误区还是讽刺的质疑，无疑是对形式化方法研究和应用的一个促进，并不能因此而“因噎废食”。由这些误区和质疑，也不难看出对形式化方法的一些“幼稚”的认识，以及由此而造成的许多误解。事实上，每一种方法都有其自身的理论背景和应用条件。同样，使用形式化方法亦要清楚其理论背景和应用条件，若将形式化方法应用于文学创作，这显然是不合时宜的。形式化方法的使用应限制在可形式化的范围之内。然而，现实世界中，并不是所有的实体都能够形式化的，这就提出了人工智能中的基本问题：常识（common sense）的表示问题，这一问题也是阻碍人工智能发展的重要因素之一。若能将常识形式化，那么，形式化方法的应用范围将能大大地扩大。在反对形式化方法的意见中，有很多是将形式化方法应用于不适用的情况而得到的结论，这也是对形式化方法认识之误区和质疑的主要来源。当然，也必须承认，形式化方法的确有其自身的局限性（如在第3 节中所述），这也是任何一种方法所不可避免的。现在并没有足够的信息和证据用以客观地评价形式化方法和其他方法对软件和系统开发过程的贡献。无论对形式化方法如何争论，我们有理由相信，形式化本身并没有错。形式化方法在技术上已显示出了可观的实力，同时我们也看到，它也限制了软件开发的范围，有些可用其他方法实现的问题，用形式化方法却无法实现或很难实现。这就要求我们能够“超越”形式化方法，深入认识软件开发过程，对软件开发中的非精确、非形式化领域予以同样的重视，以科学的研究方法来研究形式化方法。 5 关于形式化方法的几点建议及发展方向基于上面对形式化方法的分析和讨论，我们提出对形式化方法的几点可能的改进，从而也就确定了形式化方法的一些发展方向。（ 1 ）可重用的规范库及更易接受的符号系统将更有助于形式化方法的研究与应用。如：形式化方法与结构化方法符号系统的结合，即可将形式化方法的严密性与结构化方法的结构性结合起来，使得规范更易理解，更易于交流。在这方面，目前也有一些研究成果；对可重用规范的研究目前较少。当然，这一改进工作并不是短期内可以完成的。（ 2 ）改进形式规范的语法、语义定义的质量，从而可以使得形式化方法更加“稳定”。象 VDM 和 Z 这样的形式化方法，就有许多版本。因此造成了形式化方法的不稳定状况。目前已着手开始对 VDM 和 Z 进行标准化工作了。（ 3 ）加强规范语言中对并发控制和容错处理的表达能力，同时也要使精化技术能够处理这类并发机制和容错。这方面的改进也是长期的研究课题。（ 4 ）对于支持形式化方法的工具的可信度问题，一直是困扰形式化方法发展的重要因素之一，如何度量与提高支持工具的质量亦是一个长期的研究问题。（ 5 ） Bell 实验室的 P.T.Devanbu 在第十六届软件工程国际会议中（ 1994 ）指出：目前大多数软件系统的容量和复杂度日益增大，需要对软件开发过程中的各个阶段增强基于知识的描述和维护。基于知识的软件工程（ KBSE ）研究范式正是形式化的知识表示和推理机制，支持多种软件开发过程。随着 KBSE 的发展，该方式需要在基于知识的系统构造、维护、运行和理解方面增强描述能力和推理能力，而描述逻辑可在终止性、形式化语义和高效的推理过程诸方面提供有效的支持。在此，我们只给出对形式化方法研究的一部分研究方向，而未能给出关于这些研究方向的研究方法。从总体来说，若要在以上各方面得以改进，完全依赖于形式化方法研究的前人结果是不现实的，必须开辟一条新的研究道路，尽力摆脱前人结果的束缚，这样才有可能超越形式化方法，使得形式化方法得到充分的利用。另外，值得重视的是，形式化方法的研究与发展，也依赖于其他相关学科的发展，如：代数学、范畴论、逻辑、认识论、认知科学、人工智能等。数学作为计算机科学发展的基础，同样对形式化方法的发展也起着至关重要的作用。认识论、认知科学、人工智能等学科的研究能够促进对软件开发过程、智能型软件的形式开发，及知识表示等方面均有一定的重要影响。正如中提到的，真正的计算机科学家应是一个全面的人才，而不应局限于其特定的领域，应有较强的理解力。同样，研究形式化方法也应考虑其相关学科的发展及其影响。 6 结论本文以研究的态度，讨论了形式化方法的能力、局限性以及关于形式化方法的争论，从中可以窥见当前形式化方法的研究现状以及今后的一些发展方向，希望本文的讨论能够有助于正确认识形式化方法，以能提高形式化方法的效率。这也是本文主要目的。形式化方法的研究涉及许多方面，本文不可能将这些方面全部阐述清楚，有许多文献已对形式化方法的其他方面进行了讨论，如：对形式化方法的使用提出了切实可行的十点建议，并指出若依此十点建议来使用形式化方法，将会体会到形式化方法的巨大益处。对形式化方法在大型软件开发中的应用作了一个客观的论述，其中有形式化方法应用于各种领域的十五个应用实例，对每个实例详细地叙述了项目的开发者、开发目的、开发内容、形式化方法在开发中的使用、项目产品的使用、开发中所使用的工具等。对形式化方法在特殊领域中的应用方法及效果做了阐述。另外，本文也未对形式规范语言和具体的形式化方法及技术，如： VDM 、 Z 、 B 等进行讨论，这些在中均有详细讨论。对形式化方法近三十年来的研究和应用，已取得了一定的成果，但也应清醒地看到形式化方法在研究和应用中的困难和局限性，更重要的是，应注意对形式化方法研究的研究方法。对形式化方法的研究，我们认为，首先应认识到方法本身并不能解救我们，但它可以帮助我们。也就是说，要认清方法在软件开发中的地位，认识到新的方法和工具可以帮助我们，但它并不能解决根本问题。在这一认识的基础上，对软件开发过程的深入及实质性理解，对形式化方法的研究也具有很大的影响，试图通过形式化软件开发过程来研究形式化方法，我们认为是不可取的，因为软件开发过程本身是人的一种具有创造性的智力行为，在此过程中有智能的因素在起作用，如：人的直觉、常识等因素。另外，在研究模式上也应加以改进，目前的研究模式基本都是研究—推广式。这种模式实际上不符合人的认识过程，人类的认识过程是实践—认识—再实践的反复过程。因此，理想的、正确的研究模式应该是由真正的软件开发者在实际开发中提出问题，提出对形式化方法的要求，然后由研究者研究解决这些问题的可能性及方法，再将其应用于实际的软件开发过程中。这样，对形式化方法的研究就应有强大的经济支持及应用背景，以能使形式化方法充分发挥其应有的作用。当然，目前国内的研究状况很难达到上述要求，甚至在发达国家中也是不多见的。因此，一种可行的办法是，研究与开发并轨同行。研究者可以暂时不考虑其研究内容在今后是否有什么应用前景，就象纯数学的研究那样，同时开发者亦应不断地提出问题，以此来刺激研究者不断地纠正方向，使其研究渐渐地靠近应用，随着科学及其应用的不断发展，研究与应用必然会走到一起而合二为一。这时，将是科学的又一大进步，这也是科学发展的一种较现实的途径，对于形式化方法的研究也不例外。最后，讨论一下关于形式化方法的使用和适用性问题。对于这一问题的争论，实际上来源于：到目前为止，还没有足够的证据及实例能够充分证明形式化方法可以在大型软件开发中发挥其效益。当然，必须承认，形式化方法的研究者们的确在某些方面夸大了形式化方法的能力，形式化方法在理论上的能力是很可观的，也是清楚的，但对于其局限性，就有些难以将其阐述清楚。所以，最好是刺激形式化方法的使用以充分显示其价值，从而有可能越过其局限性。虽然在某些方面夸大了形式化方法的能力，但在一定的领域内，开发者仍有使用形式化方法的强烈要求。当然，这一论断是对形式化方法之复杂现状的一种简单化。无论是研究还是使用形式化方法，都应认识到，软件工程是一种人类行为，所以，形式化方法不可能保证软件产品的正确性。如果能够愿意从失败中吸取教训，愿意利用现有的最好的技术来检查我们的工作，通过适当的测试和工具，那么，我们将能成功地使用形式化方法来开发高质量、高可信度的系统。总之，形式化方法的研究和使用，具有光明的前途，但也有其不可避免的曲折，任何一门学科的研究、发展都是如此。; 个人分类: 形式化方法|3445 次阅读|0 个评论

第五届反应堆物理与核材料学术研讨会暨第二届核能软件自主化研讨: 热度 2 maxb917 2011-11-2 11:41; 这两天在重庆参加了第五届反应堆物理与核材料学术研讨会暨第二届核能软件自主化研讨，重庆天气不是怎么好，天天下雨，但下的都不大。欣喜的是看到我国核能设计所用软件正在自主研发的道路上有条不紊的进行，在MC模拟程序开发方面，比较突出的有九所的JMCT和清华大学的RMC，在核反应堆设计方面，在国家重大专项的支持下，国家核电软件中心在反应堆核心设计软件方面已经做了很多的工作，当然我们（华电）也参与了国核的软件开发。在重大项目方面，国家支持了ADS，ITER以及钍基熔盐堆等，都投入了很大的钱。所以，虽然发生了福岛核事故，但我国核能的投入还是很多的。; 个人分类: 会议交流|4151 次阅读|3 个评论

基因软件架构适合云软件开发平台的构建: Babituo 2011-10-27 22:09; 软件是开发出来的，开发是在平台上进行的，平台一定是互联网的，互联网未来是云的天下。谁抢占了应用软件的云开发平台，谁就占据了未来软件的至高点。真正意义的云软件开发平台还没有出现。如何架构一个云软件开发平台？我们是否可以开始行动了？现在的“云软件”为什么不是真正的“云应用”？因为现在的“云软件”更多地体现的是“资产性”。还只是以独立的共享软件服务的方式出现。真正的云软件，应该是一个逻辑整体的超大的逻辑云。大家共生在这个逻辑云上，共享相互关联的逻辑。云软件开发将改变软件开发的一切，赶快行动。云软件开发和现在的软件开发平台有何不同？云软件开发模式和现有的软件开发模式有什么不同？未来的企业应用应该是在云上开发出来的。想过云软件开发能给程序员带来什么好处吗？不仅仅是开发环境的共享啊。软件开发的模式可能产生重大的变革。基因软件架构非常适合云软件开发平台的构建。; 个人分类: 基因软件开放实验室|3651 次阅读|0 个评论

[转载]留住最后的激情: wolfpnc 2011-10-20 22:33; 这是好多年前从网上摘录的文章，用来激励公司软件团队的，现在转贴这里，也许对在信息技术行业的同仁有一定的帮助。引言程序人生中，最初大多激情万丈，可是历经现实的土壤之后，这种激情却在慢慢的消耗中消失。但是，这平凡的职业，却最需要不平凡的激情。拿破仑曾经说，军队战斗力的 3/4 是由士气组成。用于今天的软件业，可以说，软件团队研发能力的 3/4 是由成员的积极性决定的。之所以这样说，主要原因是开发人员的积极性很少得到过良好保护。尽管这句话有些偏激，但确实反映了当前的一些现状。有很多高级经理知道下属那种被进度折磨得疲惫不堪的惨状？有多少开发人员被无休止改变的需求折磨得厌倦了本来钟爱的职业？程序员的激情、团队的士气和积极性都在年复一年的项目中渐渐消亡，而这些很多都发生在不经意间！深夜，我常常问自己，明天是否依然珍爱这个给我带来激情的行业？在终于丧失了最热情的激情之后，我只能随着岁月，慢慢地把这种无限激情的挚爱演变成一种平凡的职业，一种平静的谋生手段。但就是这种职业，所从事人员的素质却也参差不齐。当前社会上，那种“职业化”很高的程序员们，为了高薪可以毫不犹豫地抛弃手头的工作，在代码中加入逻辑炸弹、留后门，对自己的技术进行保密，运用等等诸如此类的技术。现实中所看到的事例太多了。我不可能通过一篇文章来说明什么，但真心地希望我们国内的程序员队伍能够有更高的素质和层次，值得社会去保护，去珍重。团队失去往往是决定该团队最后能走到什么高度的关键因素，因为在高昂的士气面前，挑战困难变成了乐趣。如果连积极性也没有了，谈何创造性，更谈何拼搏精神？积极性对一个项目的重要程度，我想大家能够有所共识。而且粗想起来，积极性是一个高度抽象的事物，很难用什么指标去量化地衡量。但对词说法，真正启发我的是国外一篇文章中所说过的一句话：当一个事物不能量化的时候，就证明了我们对这个事物的认识不够深入！真是不得不佩服外过专家的认识水平。一句话醍醐灌顶，让我大长学问。所以在以后的工作中，我总是考虑 2 个问题：怎样才能把这个指标量化；有怎样把量化的数据用于实际的工作。用于保护程序员的积极性的这个问题，道理也同样。如何保护成员的积极性，首先应该建立在对团队共同目标认知的基础上。管理大师彼得 . 德鲁克有 3 个非常著名的问题：我们的事业是什么？我们的客户是什么？客户的价值观是什么？用在这里不妨改一改：我们的目标是什么？我们能为客户做什么？客户的需求是什么？如果团队里的每一个人都能很准确一致的认识和回答好这个问题，那无意这个组织就具有一致的目标。这就是对团队组织文化的一种认可。有了共同的目标，才有凝聚力，才能有更好的工作效果。如果项目中每个人心里都有一个小算盘，散沙一盘，那一旦团队出现难题，很可能项目成员心里想的就是如何保全自己的利益，最盛行的就是赶快精心准备自己的简历，再去找高薪职位！此时，再谈积极性和归属感，几乎就是空话！那么，在现实的工作和项目中，如何才能保护好团队最珍贵的资源 -- 员工的积极性？根据我的亲身感受，我想提出以下参考意见，希望能从最底层、最细节处给大家以启示：一、提升项目主管的管理水平管理知识不是简单的纸上谈兵，其中富含着很多系统的道理。很多程序员对此都不以为然，包括我自己在内，先前也是认识不足。但后来，因为一本已经出到第 17 版的《管理学教程》，改变了我的想法。很多现实中不可名状的线索或思路，根本没有系统化和深入，后来，看的相关书多了，这才慢慢地发现很多的想法其实都是有据可依的，而且很多都远不及这些著作思考得全面、详细和深入。尤其可怕的是，这些著作有很多是 60 年代甚至更早时写的，也就是说我们的管理知识甚至还低于 60 年代的水平。仔细想来，其实 CMM 就是 TQM （全面质量管理）在软件开发中的应用。所以，强烈建议每一位项目经理和希望成为项目经理的人员都看看管理方面的书籍。这绝对是提升自我的一个良好途径。通过提升项目主管的管理水平，尽可能避免挫伤团队成员的工作积极性，这也是保护和提高组织成员的工作积极性的一个极其重要和直接的手段。二、缩短激励措施的反馈时间现在大多数公司都实行年终奖制，员工的业绩在年终才会反映出来。其实，我比较反对这样的做法。如果一个员工平时工作很优秀，但是他的优秀必须在一年之后才能反映出来，除非他是一个追求卓越的人，否则他肯定会懈怠的。而且工作中，很多的项目经理很少赞扬下属。他不明白，哪怕是口头的夸奖，也是非常有效的激励手段，而且根本没有任何成本。而且它不仅能提高工作效能，更能改善工作关系，所以，何苦难开金口呢？其实，我们完全可以将年终奖改成季度奖，甚至是月度奖。当然，现在也有很多公司做出了修改，但实际上，员工是非常希望不断得到肯定的。我们可以在每周的工作日志上给员工一点鼓励，甚至一句赞扬，我们也可以给提出好建议的员工发出一个 mail ，谢谢他们的好主意。甚至，我们只需要简单而真诚地说句：“你的文档写得很好！”；“你是我们的骄傲。”“我想是我错了！”“谢谢你昨天的加班。”等等，也许效果会好的让你无法相信。也许我们无法使用太多的物质奖励，但是在物质奖励之外，高频率的、有针对性的口头激励，也能把你的员工组织演变成一支士气高昂的不凡团队。三、沟通是绝对必要的曾经有一篇国外的文章提出了一系列的问题，如果你能对每一位同事都能回答出来这些问题，就证明了你对该同事已经了解了。当然这些问题不涉及到个人的隐私，完全是工作方面的。我试了试，发现竟然没有一位同事的情况我是完全了解的。这让我非常惊讶，我竟然根本不了解我的同事，不了解他的工作经历、毕业院校、特长、专业，以及比较得意的成果等等。试问这样的情况下，还能很好地沟通吗？虽然每位主管都会有一些自己的沟通技巧，但如果知道了这些技巧，沟通起来会更加顺利，更有针对性，也更能获得更多的资料。很多人抱怨沟通没有效果，可是你真的了解你的沟通对象吗？不妨回答上面的问题试试？请注意，上述问题仅仅是所有问题的一小部分，但是已经有很多人回答不出了。况且沟通是一个持续的过程，并不是沟通一次就全部完成，人的思维、技能、认识都在不断进步。很多国外公司，每一位经理都有一个例行任务，就是每个月都必须和下属进行一次单独的沟通，这是非常好的制度。而且这些经理大多接受过沟通技巧的培训，什么开放式提问技巧、引导方式、沟通礼仪等等，可见沟通已经提到了很高的位置。但这不是中国式的训话，沟通的目的是要下属真实地表达其内心的感受，而不是听唐僧说经。在大多数情况下，下属并不十分信任上司，害怕说真话，害怕被穿小鞋，这也是经理们不专业的地方之一。大量的事实证明，最有效的沟通方式是非正式的沟通，也就是以私人身份为基础的沟通，比如就餐、度假的时候等等，总是就是抛弃身份，以真实的朋友身份进行沟通。这样，下属才能体会到自己是被重视、被理解的。如果自己的意见被采纳，或者上司能够针对下属的苦闷在日常工作中给予开导，员工的积极性会有非常显著的提高。但是切记，一定要真诚，不能只做表面功夫，更有甚者打击报复，如果这样，那这位员工估计也就开始到处浏览招聘信息了。沟通这个题目太大，需要深入其中，在此不再多说。三、不要变相地惩罚优秀员工优秀员工是公司最大的财富， GE 总裁杰克 - 韦尔奇曾经说过， 20% 的优秀员工是公司最大的财富。可是很多情况下，我们的经理们在不经意中，变相地惩罚优秀的员工，更可怕的是他们自己并未意识到这点。不信，你就可以试试下面的几个方法，这绝对是将优秀人才赶往对手公司的绝招：方法一：能者多劳自从哲人发明这句话，就害了无数的优秀人才。且渐渐变成了一种共识：优秀的员工就是应该承担更多的任务，承担最难的工作。于是能干的人工作量越来越大，每天都要加班、熬夜，可是薪酬呢，大多时候恐怕很难真正做到按劳取酬。一般而言，大多数公司内，因为大家资历相差无几，所以能干者和不能干者收入也基本一致。天长日久，优秀人才自然心生郁闷：为什么要多干，为什么要加班。积极性大打折扣，即使不跳槽，勉强留下来，工作也远不会象当初呢么尽力了。方法二：有错误就必须批评高招之二。优秀员工一般承担更多或者更难的工作，而且活越多越难，犯错误的机会就越大。于是，那些公认的优秀分子，一次又一次地被叫到经理办公室，然后黑着脸出来。而能力一般的员工因为总是分配到简单任务，且可以得到优秀员工的指导，犯错的机会小得多，由此在经理眼里反而成了精英人物，得到更多的提升机会。渐渐地，能干的人开始变得谨慎，变得没有积极性，没有激情，变得明哲保身。允许员工犯错误，但前提是必须承认错误，不要犯同样的错误。对于开拓性的、智慧型的错误，不但不应该批评，反而应该奖励。方法三：让不忙的人去吧部门有 2 个培训名额，让谁去？ A 太忙了，而且他去培训， a 模块就没有人能完成，不行！还是让 D 、 E 去吧，他们的模块简单，很快就做完了，不会影响到项目进度。这不是玩笑话，类似这样的事情就在身边发生。因为能干，别人无法替代，结果优秀人才就丧失了很多的权利和机会。但如此，你的部门肯定又会失去一位优秀员工。方法四：我们不能没有你部门有一个提升名额，可以提升一位成员任其它部门的经理。于是，经理就考虑： A 去，不行，他是部门最接杰出的成员，他能胜任很多最困难最复杂的任务，我们不能失去他。还是让 C 去吧，他的工作可以由 B 暂时接替一下，然后再招聘一个新人来就行。方法五：我没有料到会这样 A 是部门最杰出的员工、公认的技术专家，但是不喜欢在众人面前说话。可是最近他的经理要他在全公司高层人员面前讲解该部门的最新研究成果。 A 一再推脱之后还是被安排。最终怀着忐忑不安的心情走上台。结果 A 成了整个公司午餐笑料。 A 的工作效率比原来差得很远。他的经理解释道：我没有料到会这样。其实，知道有缺点，应该提早鼓励其信心，再从细处帮助更改，切忌事后看热闹再懊悔。方法六：关系领先在公司甚至部门中，不可能全部排除私人关系的存在。人才的优秀，再加上私人关系，应该是部门非常信赖的员工，但是一定要公平对待。员工非常忌讳幕后的提薪、升职之类的做法。即便当时灭有强烈地反映出来，但对于员工对公司的忠诚度、对工作的积极性都有很大的损害。类似的方法还有很多，在此不一一列举。尽管都是细枝末节，但对于员工的影响很大，实在不容忽略。任人唯贤，会给所有的员工这样的信息：只要我干得好，公司就会给我很好的发展。用一句俗话来说就是有奔头。因为有了明确的远景，追求卓越就会慢慢地成为一种生活习惯，工作积极性高涨，工作效率自然卓绝不群，当然公司也会更有竞争力。反之，如果员工感受不到认可和希望，大多数人的选择就会成为敷衍了事。四、不要认为是理所当然早晨 9 点，技术骨干 A 拿着昨天晚上做到 2 点写完的文档兴冲冲地送到项目经理 Z 的办公室。 Z 正在看电子邮件，头也不抬地说：“就放在桌子上吧。” A 有点无奈地把文档放在桌子上，无声无息地出去了。一个星期过去了， Z 没有对那篇文档发表任何意见。 A 心里想：“唉，也不知道他看了没有？还不如做一个常规的呢。” 如果将上面的情景加以修改，效果又会如何呢？不妨试试：项目经理收到了文档，并真诚地对晚上的加班表示感谢。 A 面带微笑地出去。当天下午， Z 通过电子邮件将意见反馈给 A ，赞赏之后提出几点非常有深度的意见。 A 有高兴又佩服地去修改自己的文档。这 2 个场景实施起来区别并不太大，只是多了一份赞扬、理解、关怀和反馈，但结果却迥然不同。零零总总说了这么多，希望能带给大家一丝清新，从最细小处关怀和体贴程序员这个未被好好保护的珍贵资源。; 1708 次阅读|0 个评论

[转载]22条经典的编程引言: hzkvictory 2011-9-21 15:01; 下面的这些经典的引言来自英文，也许有些我翻译的是不很好，所以，我提供了中英对照，如果有问题，请大家指正。过早的优化是万恶之源。Premature optimization is the root of all evil! - Donald Knuth 在水里行走和以一个需求规格进行软件开发，有一点是相同的，那就是如果水或需求都被冻住不了，那么行走和软件开发都会变得容易。Walking on water and developing software from a specification are easy if both are frozen - Edward V Berard Hofstadter 定理：“一件事情总是会花费比你预期更多的时间，就算是你已经考虑过本条 Hofstadter 定理”。It always takes longer than you expect, even when you take into account Hofstadter’s Law. - Hofstadter’s Law 有些遇到问题的人总是会说“我知道，我会使用正则表达式”，那么，你现在有两个问题了。（意思是：你本想用正则表达式来解决你已有问题，但实际上你又引入了“正则表达式”的一个新问题）Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems - Jamie Zawinski 调试程序的难度是写代码的两倍。因此，只要你的代码写的尽可能的清楚，那么你在调试代码时就不需要那么地有技巧。Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian Kernighan 用代码行来衡量开发进度，无异于用重量来衡量制造飞机的进度。Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates PHP被一些不合格的业余人员造就成了一个小恶魔；而Perl则是被一些熟练的但不正当的专业人员造就成了一个超级大恶魔。PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil, perpetrated by skilled but perverted professionals. - Jon Ribbens 在两个场合我被问到：“请你告诉我，如果你给机器输入了错误的数字，那么，是否还能得到正确的答案？”我并不能正确领会这类想法。（意思是：程序需要有纠错的能力吗？）On two occasions I have been asked, ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.” - Charles Babbage 在编程的时候，我们一定要想像一下，以后维护我们自己的代码的那个人会成为一个强烈的精神病人，并且，他还知道我们住在哪里？Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Rick Osborne 现代的编程是“程序员努力建一个更大更傻的程序”和“世界正在尝试创造更多更傻的人”之间的一种竞赛，目前为止，后者是赢家。 Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook 我才不关于我的代码是否能在你的机器上工作！我们不会给你提供机器。I don’t care if it works on your machine! We are not shipping your machine! - Ovidiu Platon 我总是希望我的电脑能够像电话一样容易使用；我的这个希望正在变成现实，因为我现在已经不知道怎么去使用我的电话了。I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. - Bjarne Stroustrup 计算机是一种在人类历史上所有发明中，可以让你比以前更快地犯更多的错误的发明，同样，其也包括了“手枪”和“龙舌兰酒”这两种发明的缺陷。A computer lets you make more mistakes faster than any other invention in human history, with the possible exceptions of handguns and tequila. - Mitch Ratcliffe 如果调试程序是一种标准的可以铲除BUG的流程，那么，编程就是把他们放进来的流程。If debugging is the process of removing software bugs, then programming must be the process of putting them in. - E. W. Dijkstra 教一群被BASIC先入为主的学生，什么是好的编程风格简直是一件不可能的事。对于一些有潜力的程序员，他们所受到的智力上的伤害远远超过了重建他们的信心。It is practically impossible to teach good programming style to students that have had prior exposure to BASIC. As potential programmers, they are mentally mutilated beyond hope of regeneration. - E. W. Dijkstra 理论上来说，理论和实际是一样的。但实际上来说，他们则不是。In theory, theory and practice are the same. In practice, they’re not. - Unknown 只有两个事情是无穷尽的：宇宙和人类的愚蠢。当然，我现在还不能确定宇宙是无穷尽的。Two things are infinite: the universe and human stupidity; and I’m not sure about the universe. - Albert Einstein Perl这种语言就好像是被RSA加密算法加密过的一样。Perl - The only language that looks the same before and after RSA encryption. - Keith Bostic 我爱“最终期限”，我喜欢“嗖嗖嗖”的声音就像他们在飞一样。I love deadlines. I like the whooshing sound they make as they fly by. - Douglas Adams 说Java好的是因为它跨平台就像好像说肛交好是因为其可以适用于一切性别。Saying that Java is good because it works on all platforms is like saying anal sex is good because it works on all genders - Unknown XML就像是一种强暴——如果它不能解决你的问题，那只能说明你没有用好它。XML is like violence - if it doesn’t solve your problems, you are not using enough of it. - Unknown 爱因期坦说，自然界中的一切一定会有一个简单的解释，因为上帝并不是反复无常和独裁的。当然，不会有什么信仰能程序员像爱因期坦那样感到舒服。 Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. - Fred Brooks; 个人分类: spacetime|2280 次阅读|0 个评论

软件开发人员的收入概况: 热度 2 Education 2011-8-14 10:37; 一职业介绍这个职业是一个竞争性职业，双向选择，户口，海归，学历，干部身份，钱权背景都作用不大，是少有的凭个人能力吃饭的行业。竞争性职业如果没有垄断保护，普遍工资很低，比如双向选择招收的建筑工人，营业员。但是软件开发的技术门槛高，即使拿到专业学位也需要不断更新专业技能。收入尚可，但是比不上垄断国企和官员的灰色收入，而且很辛苦。因为辛苦，而且中国人也几乎没有什么原创产品和技术，软件开发在中国无法作为长久职业，在美国可以干到老。二。软件开发人员大概收入按地区分，北京上海深圳杭州大部分软开人员工资在5000~10000，其他城市收入较低。按项目来源分，给国外作外包软件，或者在外企开发收入比较高。按工作年限分，一般应届生3000左右，3年以上5000左右，5年以上的会高一些。三大陆的枳出国就成了橘以中国人的数学基础好，密集的人口资源来说，中国人有开发软件得比较优势。但是由于官本位的管理体制，关系重于科研水平，科研浮躁，干活的累个半死，名利都归搞关系的，国内的大学，研究所，基本上没有人长期搞开发。体制外，金山，阿里巴巴等稍好一些。中国人在体制内虽然不愿意从事艰苦的开发工作，但是理工科的出国后，或到了体制外，没关系可搞，没部委经费可申请，于是老老实实干活，转向软件开发相关职业。只有软件开发人员缺口大。在欧美，一般软件开发人员年薪7-12万美元，在理工科里面算最高的。医生律师那种高收入职业，外国人进不去。对比印度，印度的人均收入是中国的1/3，但软件开发人员收入大概是数千美元/月，也高于中国。印度这样一个落后国家，其软件开发水平和规模远高于中国。大陆的枳出国或者到外企就成了橘，台湾也长橘，大陆土壤里就不长橘，那有什么办法？橘子可以买，也可以那啥，1992年中美知识产权谈判，美国人：我们是在和小偷谈判。四：关于科研经费效率尽管软件安全形势严峻，我国政治上经济上都有高额投入，也有人力优势，只有中国的科教单位有事业拨款，压制私立大学对公立大学垄断保护，有大量科技计划，985，211，863，核高基，国家地方各种点面基金，都是国家出钱，效率低。我国在这个行业落后，做出一点相对非主流的东西，比如方正汉字排版软件，比如计算机证明个别数学定理，就可以拿到国家最高科技奖。私营企业花的都是自己的钱，效率高。BILL GATES创业只有2000美元，IBM，HP,google,苹果， Facebook,CISCO,ORACLE,。。计算机公司（大多数软件为主），过去和将来，几乎都是穷人从地下室，学生宿舍做到世界领先的，没有国家扶持或者科研基金一说。一个自发的创新体制（相当于科学网里起的民科）比任何国家科技计划和扶持都更有生命力。附录1：美国各行业平均收入 http://news.163.com/11/0518/00/74A1HQ7300014JB5.html 美国劳工部发布的职业就业与工资情况年度报告：从收入情况看，全美各个行业平均年收入为4．44万美元。除管理岗位外，从事法律、计算机和信息技术相关职业、建筑设计与工程业者以及医生和金融业者的收入较高。报告还显示，美国就业岗位90％以上来自私营部门。在公共部门中，联邦政府雇员的逾五分之一在美国邮政系统。这份报告统计了包括全美22个主要职业及近800个细分职业，是美国政府公布的关于美国职业就业与工资情况的最全面的报告。附录2：CSDN 2011年国内软件行业技术人员薪资调查报告 http://yedong.blog.techweb.com.cn/archives/90.html 自2011年初，CSDN在网上发起“2011年软件行业技术人员薪资大调查”以来，引起了广大开发者们的热烈反响，短短两月时间内，近万名开发者提交了调查数据。尽管这只是中国百万开发者大军的一小部分，但他们所在的行业几乎涵盖了整个中国软件的产业链，他们的职位几乎代表了一个软件团队体系的每一个层面，而且 “一叶知秋”，所以透过这些调查数据和变化，我们或许可以一瞰中国软件开发者的普遍生存状态，甚至可帮助开发者，更准确地定位自己在产业内的坐标。 2011：程序员的日子不算差相信每个开发者在回忆当初高校毕业，加入滚滚求职大军的情形时，都能记得那番对美好生活的憧憬和闯荡世界的豪情。而在经济社会，判断成功的可量化方式无疑是薪资了，尽管有点世俗，但暂时也找不到更好的标准。那么现在，中国的程序员们，总体收入水平如何呢?首先我们看程序员们对薪资水平的满意度。我们发现绝大多数程序员(近73%)对自己的薪资并不满意，这种普遍不满意的情绪有多少是主观预期过高，多少是客观生存环境造成的呢?我们需要做进一步的考察。我们按月薪大小把收入水平划分为四类：低收入(小于2000元)、中等收入(2000~5000元)、中高收入(5000~10000元)、高收入(大于 10000元)。从调查数据看，来自中国17座重要IT城市的开发者们，占据绝大多数的是月薪2000~5000元，它在13个城市占据最高的比例，其中排前3名的是沈阳(67.5%)、济南(65.8%)、珠海(62.5%)。而北京、上海、深圳的开发者收入水平相对高些，这三座城市占据绝大多数的是月薪5000~10000元的群体。如果仅依据国家统计局公布的数据显示，2010全年城镇居民家庭人均总收入21033元(月平均1753元)，其中北京城镇居民人均可支配收入2.9万元(月平均2417元)。这两年国家经济相对比较稳定，估计2011年的情况也差不多。所以总的来说，2011年的中国程序员群体，在所处的城市里，和其他居民比，算相对收入不错的了。当然也有生存环境堪忧的，我们发现月薪少于2 0 0 0 元的群体，主要分布在济南(15.8%)、西安(13.8%)、青岛(12.7%)、武汉(12.6%)。而如果以月薪10000元(及以上)算高薪，排名前列的则是上海(26.9%)、北京(20.6%)、深圳(14.7%)、杭州(11.3%)，杭州程序员群体的崛起令人关注，说明杭州近年来的信息化建设成就卓著。再回过头来看程序员的薪资满意度，我们通过交叉分析发现，程序员的满意度确实和薪资大小相关，收入越高，不满意的比例越小。但值得注意的是，不管哪个收入群体，都超过50%以上都表达了对当前薪资的不满，说明尽管日子过得不算差，但中国程序员们的幸福感普遍不高。最佳跳槽次数，最好不超过3次跳槽，一直是程序员们在职场生涯里所面临的热点话题。它是一把双刃剑，一方面会带给你更多的视野和经历;另一方面，会降低你的企业忠诚度和所在企业平台的积累。所以很多开发者往往会面临是否跳槽的煎熬和苦恼。那么本次调查的数据显示，资薪和跳槽此数存在潜在的规律吗? 从上面的“薪资/跳槽次数交叉分析表”，我们发现在四个收入群体中，“少于2000元”和“2000~5000元”群体中的绝大多数人都未换过工作，而从收入高于5000元的群体开始，有跳槽经历的人数显著加大。从工资高于10000元的高收入群体看，我们发现有3次跳槽经历的人占据最多的比重，达到 24.6%，但从第4次开始又急剧下跌到10.3%。所以从这样的数据结果可以看出，凡是有一定收入水准的开发者，基本上是有跳槽经历的，但跳槽的次数越多，并不绝对保证薪资高。数据显示跳槽次数存在一个“天花板”——3次。看来适度的跳槽有利于经验和技能的提升，但如果跳槽过于频繁，则不利专业的积累，自然在薪资上提升的空间也不大了。技术菜鸟到牛人的距离，5年是分水岭再来看工龄和薪资的具体量化关系，我们发现工作1~2年的开发者，工资在2000~5000元之间占据绝大多数，而工龄超过2年的，大多数人的收入达到 5000元以上。同时我们发现薪资在5000~10000元群体在10年以内都基本处于一个稳定状态，没有明显增幅。而10000元以上的高收入群体，一个非常显著的变化是，前5年的人数增幅明显加快，但之后几年一直均处于稳定状态。所以，“3年(月薪5000元)”、“5年(月薪10000元)”是两个关键的分水岭。凡是月薪5000元以内的，随着工作年数的增加，人数递减;但随着年数达到3年后，月薪5000元以上的群体，人数开始显著递增。这不难理解，因为工龄的增加，开发者的工作熟练程度也越高，所以自然薪水也就高了。而工龄超过“5年”达到月薪10000元以上后的高收入群体，随后也基本开始保持稳定了。这说明，岁月对于技术开发者的薪资，同样存在一个瓶颈，并不是无限制正比例上升的。由此我们似乎可以推断，在中国软件行业，一个程序员菜鸟发展到业界认可的“熟练工”大概是“3年”，而“技术牛人”所需要的成长时间，大概是 “5年”。什么工作最赚钱?——不上班 “男怕入错行，女怕嫁错郎”。随着信息化在全社会范围内的渗透，所从事的细分行业的信息化发展水平和市场前景，已经成为决定开发者收入水平重要因素。那么作为开发者，选择什么样的工作，选择哪个行业的软件公司最有发展前景呢?调查结果令人诧异——自由职业者(SOHO)收入水准最高，超过30%的SOHO 月收入超过10000元，月收入5000元以上的比例更是超过84%。但细想也在情理之中，有勇气做自由职业的开发者，往往具备超高的技术水准和丰富的行业积累。再看具体的细分行业，高收入开发者比例最高的领域是欧美外包(21.4%)，看来中国软件本质上离“中国创造”的目标，还有很长一段距离。其次是原厂商(17.1%)，这里的原厂商指的是诸如微软、甲骨文、IBM等软件巨头，其员工收入高并不意外。排名第三的是移动和手机应用(16.9%)，这现象令人欣慰，毕竟未来就是移动互联网的时代。从调查数据看，最不合适介入的是教育行业，小于2000元的低收入者比例接近15%，月收入小于5000元的接近65%。教育产业在国家属于公共资源，被严格管理，介入门槛比较高，再加上以“高考”为指挥棒的单一教学导向，不容易衍生丰富多彩的信息化应用。此外，餐厅零售行业也是开发者需要谨慎选择的，低收入者10.87%，小于5000元的接近71%。不过餐厅零售业不像教育那样受到政府的严格管理，所以从乐观的角度，说明这个行业的信息需求没有充分挖掘。开发语言，选谁都一样工欲善其事，必先利其器。开发语言、平台对于开发者来说，如同披荆斩棘的利剑。尽管对于顶尖高手来说，达到了编程思想、方法论层面的炉火纯青，可鸟瞰一切平台和工具，但对大多数初涉软件行业的程序员来说，熟悉哪种语言、开发工具往往直接决定了当下的收入水平和生活水准。从调查数据看，绝大多数开发者都使用 JAVA，达到45.3%之高，其次是C#、C++、C、.NET、JavaScript，它们相对比较均衡，基本在25%左右(注：很多开发者往往实际会使用一种以上语言)。我们发现，C#、.NET开发者中，小于5000元的比例最高，基本在55%。但不能因此说C#、.NET没有前途，因为另一数据发现，所有的语言，在5000~10000元的群体里，比例竟然惊人趋近，基本都在30%~40%之间，这说明不管选择哪个平台，只要达到“熟练工”水准，收入不会差太远。至于一些语言的低收入群体比例偏高，这和它容易学习，适合编程菜鸟上手有关，因为我们同时通过交叉分析，注意到工龄2年内的 C#、.NET程序员小于月薪5000元收入水平的比例竟然高达80%左右，而工龄超过3年后，这个比例开始明显下降了。再看高收入群体，我们发现在使用Erlang、Perl、Scala技术的人中，高收入人群的比例较高，分别为41.2%、36.7%、36.4%。但我不建议大家一窝蜂地去学习这些语言，因为同时发现它们的样本量极低，分别是17、98、11，远小于近万份的总样本量，看来主要是物以稀为贵，会的人少，自然收入就上去了。本文来自《程序员》杂志11年04期吴仪谈判 http://www.people.com.cn/GB/32306/99407/7059710.html 【2】程序员真的是吃青春饭的吗？(献给即将进入职场的程序员们) 又有学生问我：程序员真的是吃青春饭的吗？我是不是做到三十岁就该考虑转型了？我告诉他们：这是中国的记者们用统计数字造下的一个弥天大谎，当我们看到微软集团内的许多白发程序员在兢兢业业地工作的时候，我们又用观念来说明中国的程序员吃青春饭的原因。实际上，不仅美国的微软，甲骨文，Adobe,暴雪，在中国的金山，寰宇，腾讯，盛大，都有或者将要有年龄很大的程序员，关键是他们做的东西和那些挨踢们不同，他们做的是产品而不是项目。打个比方：微软为开发win98而雇佣了一名程序员，当win98推向市场开始盈利的时候，这名程序员不会被辞掉，因为发布出去的产品可能有bug,可能需要升级，这些都需要这名程序员去维护(新招一个的维护成本更高)，于是这名程序员不会因做完一个产品而被鸟尽弓藏，而是被充分利用起来，继续开发新的版本，这名程序员同时也能享受到产品盈利带来的利益。这样一个版本一个版本地做下来，虽然年龄大了，头发白了，但他会对这个产品更加熟悉，这是任何新手都无法超越的优势，而微软则会尽量用他直到他退休。(当年寰宇开发仙剑奇侠的团队，巨人开发征途系列产品的团队，金山开发剑侠情缘的团队除了自己创业的就根本没有人转型) 另一个比方：某家项目型公司雇佣了一名程序员去开发一款电信的项目，当这个项目完成后，这名程序员的使命就完成了，顶多留下一两个核心成员进行维护。当项目的尾款全部到位后，连维护的人员都可以省略了。因为项目完了，钱拿到了，人就没用了，继续雇佣就是白拿工资了。当然，如果有新的项目，可以把这名程序员派到新的项目上，因为项目大多是竞标的，项目款是有上限的，除掉人员开销等开支就是公司的利润。所以这名程序员的工资向上的空间是有天花板的。当这名程序员年龄大了，加班加不动了，工资也涨到一定程度了，好，新人的成本更低，精力更旺盛，虽然经验欠缺点，但只要有一定经验的人带着，就可以组成一个阶梯式团队，可以以更物美价廉的组合去开发新的项目，这里没有工资高，年龄大，精力不济的老手的位置，该裁员了。 08年金融危机，各大IT企业裁掉的绝大多数都是外包或项目型团队。像巨人，盛大，腾讯等产品型公司虽然也传出过裁员消息，但裁掉的大多是推广，渠道等非技术型团队，2011年腾讯在大规模裁撤测试人员的情况下还继续加大了在开发，产品，设计等岗位的校园招聘。一般来讲，除非一家公司改变思路，下决心砍掉某款产品，否则他就必须保护参与这款产品的开发人员。所以，与其说程序员是吃青春饭的，不如说：做项目的程序员是吃青春饭的。那么做项目的程序员就没出路了吗？就必须到35岁转型吗？也不是，做项目的如果专注与技术，而这项技术又是别人极少掌握的，那么可以靠这个一招鲜做到退休。大多数项目型程序员最好的办法是积累某一行业的行业背景，比如：做电信的无论跳槽还是外包尽量只做电信的项目，做银行的尽量只做银行的项目，那么十年后，你所积累的深厚的行业背景知识就是你做到退休的最好保证，因为那是任何新人无法取代的。现在需要转型的那些挨踢几乎全是在年轻时代跳来跳去，哪里有项目就去哪儿，哪里钱多就去哪儿，到年龄大了才发现自己会的就那些东西，没有什么可凭借能扎下根来的东西。所以，能够靠到一款好产品或靠到一个好行业是一个程序员可以安身立命的终极法则。而能够做到上述两点的程序员在中国实在是太少了，中国的大公司大多是项目型公司，他们接项目，做项目，项目多了扩大规模，没项目了缩减规模。程序员们或者自己跳，或者挨踢，哪里钱多去哪儿，漂泊到三十好几，终于知道自己该有个稳定的地方了，但做完一个项目又找下一个项目的职业稳定不下来，怎么办？转型，于是做了不少项目，终于人老珠黄，青春献给IT,铸造了程序员吃青春饭的律条。按照上面的分析，新入职场的程序员们该知道怎么办了。趁青春还在的时候，找准方向，扎根于一个长远的行业或有前景的产品，那么你的未来就无忧了。以此献给刚入职场的新程序员们。【3】http://bbs.gter.net/thread-1700869-1-18.html曾　　倘若把编程语言比作人类，那么，他们在一起聚餐，会聊些什么呢？下面是笔者对原文的摘译。　　有一天，你下班回到家，发现屋里一片忙碌，妈妈告诉你，编程语言里的各位亲戚今晚要来拜访，让你赶紧打扮打扮。你进入客厅，发现C和 C++ 在争论些什么。　　C：“你个小屁孩！不要教我编写代码，等你长大了再说。” 　　C++笑笑，你也被迫加入到这个讨论中。C已经 42 岁了，是这个房间里岁数最大的语言，而排在第二的则是C++，今年 37 岁。在外人看来，他们两人看起来几乎是一样的。　　C++：“爷爷，你叫我小孩，至少我仍然意义非凡。” 　　C：“我更加有意义，孩子。如果没有我，操作系统、编译器和嵌入式系统都将失败或者不复存在，同样，如果没有我，你们这些现代语言也活不了几天。” 　　C++：“我知道。虽然我可以接管你的角色，但是我并不想，因为我为大公司编写代码已经赚了很多钱。” 　　C#：这时，你年轻的表弟 C# 走了进来。“你们两个老头子，现在，许多大公司更加喜欢我。” 　　CC++：齐声说道：“不，他们不喜欢你。” 　　C++：“我们两个一个月赚的钱比你半年赚的都多。” 　　C#：“不，你们不能。我比你们年轻，我很酷。” 　　C吐了一下：“我仍然不喜欢你对 Visual Basic 所做的。” 　　C#举起手：“大多数时候，并不是我干的。是 MicroEvil 做的决定，我发现的时候已经为时已晚了。” 　　Visual Basic 正在角落里哭泣。自从 MiscroEvila 公司迫使他进行整容后，让他更像 C# 了。他们心想，如果他能像 C# 那样既年轻又漂亮，他还能赚很多钱，可是他整容失败了，现在，他只有通过哭泣才能缓解痛苦。C和 C# 对他都感到很抱歉，并且给了他一颗止痛片。　　饭好了，大家都坐在桌子旁，最后一个来的是 Java。他穿着一件相当旧的T恤，拿着吉他，真是糟透了，他已经数周没洗澡了。　　Java：“嘿，伙计们。我终于会谈吉他了，我现在能谈一整个完整的曲子。” 　　Java 再次酷了一把，尽管他至少已经有 20 年没这样酷过了。　　Java 拿起吉他，谈起了曲子：‘Twinkle Twinkle Little Star’，只有他一人知道这个曲子，并且他已经谈了好几周。当他完成曲子后，每个人都很有礼貌地鼓掌。C一脸的轻蔑，而 C++ 则把手搭在 Java 肩上并且低声对他说。　　C++：“还记得我们讨论过什么吗？我们试着对年轻一代好点？” 　　Java：“我将对他们更好，如果他们赚到钱。” 　　C++：“他们会的，有一天我们都将会退休，真希望孩子们能赶上来。” 　　C点头：然后朝一个陌生面孔看去：“你是谁？” 　　Delphi：“我叫 Delphi，你的表妹。” 　　C：“从未见过你。” 　　其它人也点头，这个 Delphi 伙计是谁？C#说到：“你竟然是一门编程语言？有人用你吗？” 　　Delphi 指着他的宝马说：“比你赚的多，高调的小子。” 　　母亲走到中间：“大家不要吵了，你们会吓坏 Cobol 的。” 　　Cobol 已经在餐桌上睡着了，并且口水都流到了桌布上。你看到一个年轻的印度小伙站在他旁边，他差不多就是个十来岁的青少年。他向你微笑。并且害羞的说：“你好。” 　　你也说了句“你好，”并且正在好奇他究竟是谁。妈妈走了过来，介绍说：“他叫 Vishal，来自印度，你的太老爷 Cobol 已经太老了，我们正在训练他接替太老爷的工作。” 　　主人：“他看起来很年轻。” 　　妈妈：“是的，他才 13 岁。他的家族想要一部 iPhone，所以把他卖给了我们。我们已经宣布他是一个非常重要的计算机资源，顺便说一下，他不需要签证，并且无需支付任何工资和税前。他睡在厕所里，并且每天工作 16 个小时。” 　　Vishal 笑着说：“仅仅在两周里，我已经给一个公司带来了 5 万美元的利润。CEO 和执行主管已经分得了数额的奖金，为了表达感谢，他们说我可以睡在厨房里了。这样大家上厕所的时候，我就无需起床了。” 　　Cobol睡醒了，说到：“不错，好样的，他正在完全接管我的角色。现在，他要是能把我的尿不湿换了就好了。”说完，Cobol 又回去睡觉了。　　你看到一个空桌子旁有两个男人坐在那里，他们戴着单片眼镜、喝着美酒，　　他们好像在窃窃私语讨论些什么。　　主人：“那是谁，妈妈？”你问道。“为什么他们没和我们坐在一起？” 　　母亲让你保持安静，并且告诉你，他们两个是贵族。他们太优秀了，不能和我们坐在一起。　　Hashkell：其中一位男士站了起来，并且推推他的单片眼镜。“没关系，老朋友，让我们自我介绍一下。我叫 Hashkell，是一门纯种语言。” 　　Lisp：另一位也站了起来，并自我介绍道：“我叫 Lisp，出生在贵族的语言。”他小啜一口佳酿。“嘿，老朋友，这酒真是美味极了。” 　　Lisp：“嘿，小伙子，这是 1970 年的 Chateau de Le Fancy Pants，将近 800 美元。” 　　C++说道：“那是我支付的，因为你们两个已经不工作了。” 　　Lisp：“亲爱的，我们可是纯正的血统、纯数学语言。我们代表着美丽、真理和优雅。你也不希望我们的手变脏，编码就好比猴子在剥花生。” 　　C#说道：你知道的，“我们是为了生存才工作的，我们并没有变成猴子。” 　　Lisp 接过话题：“你看过我们的代码吗？我们是如此的优雅、美丽，每个人都喜欢我们。” 　　他们都摸了摸自己的头发，Haskell 说道：“我们是如此的美丽，如果我们走到了现实中，我们的美丽就会减分。” 　　Haskell：“Yeah. We would become like you guys. Even being in the same room as you plebeians is sucking my coolness.” 　　C说道：“不要理他们，我们努力奋斗。” 　　晚餐结束了，大家陆续离开。你和大家道别，并感谢他们的到来。然后去擦桌子。正当母亲洗完碗，LolCode 出现了，并且说道：“能来些吃的吗？” 　　看完他们的对话后，你更加喜欢哪一位呢？你们猜到了文中的主人是谁了吗？大家不妨一起讨论讨论吧。 http://news.sciencenet.cn/htmlnews/2016/1/337436.shtmh 2015高校毕业生动向：北大爱金融清华爱软件北大本科毕业生首选的就业领域为金融业（１７．６１％），而清华本科毕业生则首选软件业（２１．３０％），其次是房地产业（１３．８％），金融业（１２．２％）排第三，选择国有企业的应届生约占三成。; 个人分类: 计算机|15362 次阅读|3 个评论

【NoteExpress】软件开发人员招聘信息: 热度 1 smilesun 2011-7-29 11:27; 因为自己一直在做文献管理软件推广，故和国内相关公司有些联系。北京爱琴海乐之技术有限公司开发的文献管理软件NoteExpress是国内最好的单机版软件。很多功能超越了老牌的文献管理软件Endnote。为进一步深入开发NoteExpress，为广大科研工作者造福，公司诚聘有志从事该项工作的人才。下面是公司的简介、要求和联系方式。请感兴趣者直接与公司联系。 =============================================================================== 公司介绍：北京爱琴海乐之技术有限公司，国内知名文献管理软件NoteExpress开发者。联系方式：NoteExpress@126.com 工作地点：北京和廊坊岗位职责描述：从事公司产品相关软件开发、测试工作；进行软件详细设计，代码编写，单元测试，集成测试等；进行软件代码的维护和改进工作；完成测试方案规划及测试用例设计和执行工作；完成部门安排的其它研发相关工作；任职要求：（1）学历：正规院校本科及以上学历；计算机专业；（2）熟悉研发常用软件（JAVA），熟悉目前广泛使用的一些Frameworks，包括 Spring/iBatis/Hibernate；有数据库开发经验优先；（3）具有互联网网站开发经验，具有大型网站开发经验者优先；（4）对计算机有强烈兴趣和天赋者不受以上限制；; 5221 次阅读|1 个评论

[转载]软件工程史上最大的误解：瀑布流程的真相: 热度 3 zlhua 2011-7-19 23:15; 今天突然发现 WWW.SOSO.COM 居然很好用，呵呵，还有GOOGLE,真是太让我热爱了，想要什么资料都可以搜到，真是太感谢了。。。。 http://group.vsharing.com/Article.aspx?aid=1095457 近 20 年来，国内 IT 项目和软件开发的主流是瀑布式流程（Process）。与瀑布模型相对的是 IID（迭代递增式开发）模型。敏捷大师 Craig Larman 和软件工程权威 Victor Basili 教授在 2003 年发表于 IEEE Computer 杂志的封面文章《Iterative and Incremental Development: A Brief History》中为我们讲解了一段非常精彩的有关瀑布模型的历史故事，这也可以说是世界软件工程史最大的误解之一。 google:iterative+and+incremental+development+a+brief+story 几十年来大家所熟悉的软件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 发表于 1970 年的著名文章 "Managing the Development of Large Software Systems" (Proc. Westcon, IEEE CS Press, 1970, pp. 328-339)。自此，世界上很多人错误地认为 Royce 大师在这篇文章中倡导的是对于软件开发，尤其大型、复杂系统和产品的开发，应当采用当今大家早已烂熟于胸的瀑布模型，即一个严格、顺序（sequential）、单次（single-pass）的瀑布生命周期，也就是说一个 IT/软件项目应该包括这样几个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码实现阶段和测试阶段、部署阶段等等。而实际上瀑布之父 Winston Royce 真正倡导的是什么？他建议的其实是 do it twice，一个两次瀑布的“迭代”模型！ If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version in so far as critical design/operations areas are concerned. Winston Royce 的儿子、著名软件工程专家、RUP 创始人之一 Walker Royce 后来这样形容他父亲和那篇著名的文章： He was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. The rest of his paper describes within the context of the 60s/70s government-contracting models (a serious set of constraints). 好了，几十年来被大家所公认的“瀑布之父”其实一直倡导的是迭代、递增和演进式开发，他在那篇经典文章中描述的瀑布模型，其实只是一种最简单的情况，并不是普遍适用所有的软件产品和系统开发、信息化和系统集成项目。而现在看，瀑布也肯定不是一种先进和最佳的软件生命周期解决方案。怎么样，业界的以讹传讹现象很严重吧，从 1970 年代开始，一传就传了近 40 年！ CMM 和 CMMI 是过去 10 年的主流。令人遗憾的是，很多人误以为 CMM、CMMI 的缺省、默认标准就是瀑布式，瀑布式是全球软件工程界的最佳实践！附录： waterfall.pdf history-of-iterative-larman-and-basili-ieee-computer.pdf; 个人分类: 快乐学习|3382 次阅读|4 个评论

[转载]支持面向服务软件开发与运行的云平台: baiyunrui 2011-7-9 20:39; 支持面向服务软件开发与运行的云平台来源：北京航空航天大学计算机学院作者：王旭孙海龙刘旭东周超 1 引言传统软件开发过程中，开发人员一般需要经过需求分析、系统设计、系统实现、系统测试等几个阶段。这些阶段的完成要求开发人员必须购买和安装各种各样的开发工具。除去开发工具在本地安装过程中繁琐的配置工作，开发人员在系统测试时一般还要自己负责购买和维护一个测试环境。特别是在分布式软件的开发时，运行环境一方面要求开发者付出不小的经济代价，另一方面将不可避免地要进行繁琐的系统安装、配置以及后续的维护工作。但是，从根本上来讲，开发人员应该专注于系统本身的逻辑实现，而不是深陷于开发工具以及运行环境的零碎工作中。所以，如果存在一种按需可取、即时可用的“开发”服务，它把所有的开发工具和运行环境以一种能力的形式提供出来，那么将会把开发人员从繁琐的外部工作中解放出来，从而减轻开发人员的开发难度，减小整个软件的开发周期。随着互联网的快速发展，企业应用呈爆发式增长。由于业务需求的多样性和复杂性，企业之间开始寻求一种跨企业的应用集成方法。面向服务的软件开发方法由此应运而生，它致力于制定企业应用的标准开放接口、通信协议，并以之为基础解决跨企业的应用集成问题。随着面向服务软件开发方法的进一步发展，它逐渐演变为一种新的分布式软件开发方法。这种开发方法讨论如何按需、动态的集成现有的服务组件，从而快速开发出满足新需求的分布式软件，这个过程也称之为服务组合。以业务流程为核心的服务组合是面向服务软件开发方法的主流实现之一，类比传统的软件开发方法，它需要业务建模、组合服务编制、组合服务验证、组合服务测试等几个阶段。同样地，以业务流程为核心的服务组合是一个相对复杂的过程，每个开发阶段都需要相应的开发工具的支持，在测试时也需要分布式部署和运行环境。这就使得开发人员不可避免地需要自己处理开发工具和运行环境的问题。而我们工作的目标就是提供一种即时的开发、部署和运行环境，支持以业务流程为核心的服务组合的整个开发过程，使开发人员避免安装、配置、维护开发工具和运行环境的额外工作。近年来，云计算无论在工业界还是在学术界都已经被公认为一种新的计算模式，它强调通过因特网来进行软件的透明分发，软件以服务的方式提供使用。从服务模式的角度划分，云计算应用可以分为 SaaS （软件即服务）、 PaaS （平台即服务）、 IaaS （基础设施即服务）三种。无论是那一种服务模式，用户都可以通过因特网透明的即时访问云计算应用，而不用关心后台的具体实现细节以及物理设施的具体位置。在本文的工作中，将尝试采用云计算技术来构建一个支持面向服务软件开发和运行的云计算平台，目的是使开发过程变得更加轻松和容易。目前在这个方向上已经有了一些相似的工作。 IBM 开发的 Smart Business Development and Test Cloud 帮助用户设计和实现柔性的开发和测试私有云环境。 Hajjat 等讨论如何将传统的企业应用程序迁移到云计算环境中。另外，在以前的工作中，我们已经开发了一个面向服务的软件生产线系统，它包括一个面向服务的软件开发工具集、支持组合服务运行的中间件以及用于原子服务存储的服务库。支持面向服务软件开发与运行的云平台的基本思路是将面向服务的软件生产线改造为云计算应用，实现在面向服务软件开发过程中的即时开发、部署和运行。本文第二章讨论已有的面向服务的软件生产线系统的不足，分析工作的动机；第三章介绍支持面向服务软件开发与运行的云平台的体系结构、系统实现以及其中的关键问题；当前的研发进展在第四章给出；第五章将总结本文的工作。 2 问题分析 2.1 面向服务的软件生产线面向服务的软件生产线是一个基于 Web 服务技术的面向服务软件的生产系统。它可以支持面向服务软件开发的整个生命周期。该系统着重解决了三个方面的问题：（ 1 ）服务资源管理。把分散的、无序的、自治的 Web 服务通过组织管理使之变得相对集中、便于发现和可信；（ 2 ）组合服务设计和开发。以业务流程为核心，通过业务建模、组合服务编制、组合服务验证和组合服务测试等阶段实现组合服务设计和开发；（ 3 ）组合服务运行和演化。实现基于 BPMN( 业务流程模型标记 ) 规范的组合服务解析执行引擎，支持组合服务演化，并对组合服务的运行过程进行监控。 2.2 问题思考和分析即使面向服务的软件生产线为面向服务软件的开发和运行提供了几乎全面的解决方案，但在实际使用中还是存在一些问题。首先，软件开发人员必须在本地计算机上下载、安装以及配置开发工具，由于组合服务开发过程依据所开发的程序需求的复杂性一般由多个步骤组成，而每个开发人员也有其承担的开发角色，这使得开发工具的维护工作并不容易。当开发人员需要更换开发用计算机时，开发工具的安装配置这一繁琐的工作又不得不重复一次。而且某些开发工具的版本升级也可能会带来整体上的冲突。其次，在测试阶段，开发者需要一个良好的测试环境。由于面向服务程序的高度分布式和动态性，搭建一个有效的测试环境将面临不小的挑战。对开发人员来说，他们不仅要获得足够的物理基础设施（一般需要物理集群），而且需要动态确定每个原子服务和组合服务的部署策略。对于第一个问题，可以把开发工具以 SaaS 的方式提供给开发人员，开发人员无论何时何地、只要通过网络即可访问到最新版本的开发工具，也避免了工具的配置过程。对于第二个问题，可以构建和维护一个集中的服务化软件应用引擎。用户根本不必关心具体技术细节和物理实现，只关注服务化软件应用引擎对外提供的功能。上述提出的解决思路与云计算技术的实现方式基本一致，下文将详细介绍具体的解决方案。 3 支持面向服务软件开发与运行的云平台 3.1 体系结构支持面向服务软件开发与运行的云平台按照功能可以划分成三个模块：服务资源共享平台、在线和本地开发环境、服务软件应用引擎，见图 1 。其中，服务资源共享平台负责 Web 服务资源的注册和收集、 Web 服图 1 云计算平台三大模块务的组织、服务关系挖掘、服务可信保证以及服务搜索等。服务资源共享平台中的服务资源是服务组合的基础；在线开发环境以 SaaS 模式提供面向服务软件的各种开发工具，使得用户通过浏览器就可以进行软件开发。而本地开发工具集则是面向服务的软件生产线系统中主要开发工具的集合，通过对原系统中各开发工具的改造，使得它们开发出来的服务软件可以透明部署到服务软件应用引擎中执行；服务软件应用引擎是一个以 PaaS 模式对外提供服务的服务软件部署和运行环境，无论是在线开发环境，还是本地开发工具集开发出来的服务软件，服务软件应用引擎都可以按需的动态提供相应的资源并在这些资源的基础上执行该服务软件。当服务软件的开发者希望分享自己的作品时，他们也可以将自己的服务软件注册到服务资源共享平台中，重新作为新的可重用服务资源。基于云计算平台的三个模块，可以减轻面向服务的软件开发人员的工作，提高他们的开发效率，实现面向服务软件开发的即时开发、即时部署和即时运行： (1) 即时开发。由于开发人员需要组合的 Web 服务以及组合用的开发工具都可以通过浏览器直接访问，所以一旦需求确定，开发工作可以即时开始；（ 2 ）即时部署。在服务软件开发完成后，开发人员可以直接使用在线开发环境中的部署工具（或者使用服务软件应用引擎提供的接口）进行软件部署，而服务软件应用引擎立刻动态的分配 Web 服务容器和组合服务引擎，并将服务软件传输到合适的计算机节点，完成服务软件的部署；（ 3 ）即时运行。只要服务软件部署成功，用户即可使用在线开发环境中的执行工具（或者使用服务软件应用引擎提供的接口）进行服务软件的执行。图 2 云计算平台体系结构云计算平台的体系结构如图 2 所示，它参照三种类型的云计算应用采用三层结构来说明系统的整体结构。 PaaS 层就是服务软件应用引擎 AppEngine ，它向 SaaS 层提供一个面向服务的软件部署和运行环境。服务软件应用引擎有些类似 Google App Engine , 但 GAE 只为 Java 和 Python 应用提供部署和运行支持，并不支持面向服务的应用。基本上，只要服务软件开发完成，用户通过 AppEngine 提供的接口进行部署， AppEngine 就动态地调度服务容器和组合服务引擎，并把服务软件部署到合适的计算节点上。部署成功后，用户就可以使用执行接口进行调用。整个部署和调用过程对用户来说是透明的，不用关心具体的实现细节和物理环境。 SaaS 层包括服务资源共享平台 ServiceXchange 和个人在线开发环境 MyCloud ，利用 ServiceXchange 中的 Web 服务和 MyCloud 提供的各种在线开发工具，用户可以不用安装任何程序就可以开发出复杂的组合服务应用，并且可以进一步的部署到服务软件应用引擎 AppEngine 中，进行运行和监控等。 3.2 服务资源共享平台 ServiceXchange 服务资源共享平台 ServiceXchange 主要用于收集可用的 Web 服务资源，为 MyCloud( 或本地开发工具集 ) 中进行服务组合提供能满足用户需求的原子服务。但由于 Web 服务所具有的分散、无序以及自治等特点， ServiceXchange 面临着一系列挑战：服务资源汇聚。 Web 服务资源数量虽增长迅速，但比较分散。一方面可以通过网络爬虫从各个 Web 服务集中站点收集，同时爬取各个 Web 服务的功能描述信息以及用户反馈等；另一方面可以鼓励用户分享自己开发的 Web 服务。服务关系挖掘。由于 Web 服务数量大，且组织无序。为了提高服务发现的效率，必须预先对 Web 服务进行关系挖掘。 Web 服务之间的关系包括相似关系、可连接关系等，可以通过语法分析、语义分析以及 Web 服务行为挖掘等得到，而挖掘出来的服务关系既可以帮助用户快速查找到需要的服务，也可以在动态服务组合中提高服务发现的速度和准确度。服务可信保障。 Web 服务的自治性特点使得它具有动态、多变和不确定性。为了保证服务资源的可信，可以通过探测程序实时获取 Web 服务的 QoS 数据，另外加上用户的各种反馈信息和评价，综合考虑 Web 服务的可信性。图 3 Web 服务搜索图 4 Web 服务订阅 ServiceXchange 目前支持关键词、 Xpath 以及 Tag Cloud 等方式搜索 Web 服务，见图 3 。通过 Web 服务搜索功能以及 Web 服务关系，用户也可以快速定位自己需要的 Web 服务，如图 4 所示。而且， ServiceXchange 采用的多种可信保障手段能满足用户对服务可信性方面的要求。对于最终确定的 Web 服务，通过服务订阅用户可以将它订阅到 MyCloud 开发环境中。 3.3 个人在线开发环境 MyCloud 与本地开发工具集个人在线开发环境 MyCloud 由一系列支持面向服务软件开发的在线工具组成，用户通过浏览器即可访问。它从原子服务的部署、业务流程建模、组合服务编制、组合服务部署和组合服务测试等方面全面支持组合服务的开发、部署和运行。 MyCloud 的关键问题包括：（ 1 ）个性化的在线开发环境。在实际情况下，所有用户的相同开发工具都由同一个程序实体执行获得，但 MyCloud 针对每个用户都应该是不一样的，因为他们的数据、状态不可能一样，为了排除服务软件开发过程中的相互影响，每个用户的开发环境应该是相互隔离、且具有个性化特征的。开发环境之间的隔离通过数据库层次的多租户模式来实现，而开发环境的个性化特征则通过用户配置的方式体现。（ 2 ）完善的在线开发工具支持。 MyCloud 的核心开发工具包括虚拟服务容器、轻量级的业务流程集成开发环境、虚拟组合服务引擎和组合服务测试工具。虚拟服务容器 MyServiceContainer 是对服务软件应用引擎中原子服务相关接口的封装，可以部署、调用、反部署原子服务，也支持原子服务在应用引擎中的调试功能；轻量级的业务流程集成开发环境 BPIDE_Lite ，如图 5 所示，它采用 Adobe Flex 技术实现，只要安装适当版本的 Adobe Flash 插件，用户通过浏览器就可以使用这个工具进行复杂的业务需求表达，形成 BPMN 规范的描述文件。在 BPMN 模型的基础上，用户可以使用 ServiceXchange 中订阅的 Web 服务以及在 MyServiceContainer 中部署的 Web 服务或者第三方的 Web 服务进行组合服务编制；组合服务开发完成后，可以通过虚拟组合服务引擎 MyBPMNEngine 部署到 PaaS 层的服务软件应用引擎中；对于部署成功的组合服务，开发环境中的组合服务测试工具，见图 6 ，能够在线的进行调用和监控，监控信息包括组合服务的执行状态以及中间参数的数值，用户通过测试工具可以判断开发出来的组合服务是否满足需求，如果不满足，则使用 BPIDE_Lite 进行修改后再测试，整个过程不断迭代直至开发出满足需求的组合服务。图 5 BPIDE_Lite 截图图 6 组合服务测试工具截图虽然 MyCloud 功能强大，而且在某些工具上采用了 Adobe Flex 技术，但它不可避免的存在一些缺陷，比如，无法实现较复杂的用户交互体验，由于网络延迟带来的某些操作响应缓慢等。所以，继续提供功能更加强大，用户体验更加丰富的本地开发工具集对开发人员来说是有益的。不过，这需要对原有的面向服务的软件生产线系统进行改造。改造的主要思路是把调用本地 API 改为远程调用 PaaS 层服务软件应用引擎暴露出来的 Web APIs 。 3.4 服务软件应用引擎 AppEngine 服务软件应用引擎 AppEngine 是一组以平台即服务模式提供出来的安装在物理集群环境上的中间件套件，它们通过 SOAP 和 HTTP 等通信协议对外暴露出功能接口，动态地调度集群上的计算资源以满足用户的各种服务软件部署和执行请求。服务软件应用引擎 AppEngine 从逻辑上可以分为三个部分： AppEngine 业务层、软件设备层和对外接口层。 3.4.1 AppEngine 业务层 AppEngine 业务层是服务软件应用引擎的核心模块，它完成对 Web 服务和组合服务的部署、反部署、执行和监控功能，并进行日志管理和提供数据存储服务，如图 7 所示。 AppEngine 业务层框架从里到外是内核、图 7 AppEngine 业务层框架各业务组件和软件设备管理器 SA Manager ，它的整体结构借鉴了 Apache ServiceMix 项目，并在它的源码基础上修改实现。 AppEngine 业务层内核部分的主要作用包括多个内核间的集群通信、对请求消息的路由和转发、对业务组件的管理等。原子服务部署 / 反部署组件实现对原子服务的部署和反部署操作。原子服务调用组件支持对已部署原子服务的调用。组合服务部署 / 反部署组件可以对组合服务进行部署和反部署。组合服务调用组件实现对已部署组合服务的调用功能。组合服务监控组件可以满足用户对正在执行组合服务的状态查看和中间变量的监视需求。日志分析和获取组件支持对下层计算节点的日志获取和分析。数据存储组件是对分布式数据库系统 HBase 的封装，它在服务软件应用引擎内部提供数据存储服务。软件设备管理器 SA Manager 是软件设备层的一部分，它负责转发和处理各个业务组件对软件设备层的请求。软件设备层面向服务的软件在执行中需要的核心中间件有 Web 服务容器和组合服务执行引擎，为了方便管理和调度，软件设备层把虚拟机操作系统（或物理机操作系统）加上 Web 服务容器或组合服务执行引擎的整体作为一类软件设备。如图 8 所示，软件设备层中的 SA Manager 主要负责调度、管理下层的 Web 服务容器和组合服务引擎两种软件设备， Web 服务容器采用 Apache Axis2 容器，组合服务引擎是原面向服务的软件生产线中使用的基于 BPMN 规范的组合服务执行引擎 BPMNEngine ；虚拟机或物理机上的代理模块 Agent 负责管理和调度本机上的软件设备；两种软件设备本身则分别作为原子服务和组合服务的运行容器。图 8 软件设备层结构图软件设备层实现的系统功能包括：（ 1 ）软件设备的动态部署、反部署；（ 2 ）软件设备生命周期管理；（ 3 ）软件设备的性能检测和反馈；（ 4 ）软件设备运行日志存储和反馈；（ 5 ）弹性的软件设备调度和管理；（ 6 ）软件设备容错以及错误恢复。 3.4.2 对外接口层对外接口层是服务软件应用引擎对外提供服务的所有接口的实现层，它接收用户的请求消息，在权限许可的条件下自动寻址到对应的业务组件进行处理。目前系统对外提供的核心 Web API 见表 1 。表 1 核心 Web APIs 序号业务组件 Web API 功能描述 1 原子服务部署组件 deploy 根据可靠性高低，冗余部署原子服务 2 原子服务反部署组件 undeploy 反部署原子服务 3 原子服务执行组件 WebServiceInvoke 平衡负载，执行原子服务调用操作 4 组合服务部署组件 BPMNDeploy 组合服务的远程部署 5 组合服务反部署组件 BPMNUndeploy 组合服务的远程反部署 6 组合服务执行组件 BPMNExecute 组合服务的调用执行 7 组合服务执行结果查询 BPMNExecuteResultQuery 查询执行中间状态和最终结果的信息服务软件应用引擎目前支持用户通过三种方式来使用它对外提供的接口，分别是：（ 1 ）使用 SaaS 层提供的开发工具。这种方式最简单便捷，但不支持批量调用；（ 2 ）直接通过 HTTP 或 SOAP 协议来调用，该方式需要用户遵循相应的调用协议。优点是与开发语言无关；（ 3 ）使用 AppEngine 的调用库 appengine.jar ，它面向第三方的 Java 开发人员，支持所有 Web API 的调用。 3.4.3 AppEngine 中的关键问题服务软件应用引擎 AppEngine 作为整个云计算平台的运行支撑环境，既要在满足用户需求约束的情况下提供不间断的部署和运行服务，还要统筹调度软件设备资源以免计算资源的浪费或者能源的低效。为了解决这些问题， AppEngine 的设计和实现中面临着以下的挑战：（1）按需的软件设备提供。服务软件应用引擎具有 Web 服务容器和组合服务执行引擎两种软件设备，这里假设当系统需要创建一个软件设备时，某些 IaaS 服务提供商（比如 Amazon ）可以立刻提供一个包含虚拟机实例的设备镜像用于创建软件设备；当关闭某个虚拟机内的所有软件设备时， IaaS 服务提供商可以立刻使该虚拟机进入休眠状态。根据与用户之间的服务等级约定，服务化软件应用引擎将采用按需的软件设备提供方式，弹性地动态调整 Web 服务容器和组合服务执行引擎的数量以及位置，达到既满足用户需求，又最大化地减少整个系统的资源消耗和能源消耗。（2）服务隔离。由于服务软件应用引擎的集中运营特点，用户的第三方 Web 服务和组合服务不可避免地要在服务软件应用引擎所部属的系统环境中运行，为了保证系统环境和用户资源的安全性，必须对 Web 服务和组合服务进行隔离处理。面向 Java 开发的 Web 服务，服务软件应用引擎采用静态代码检测和动态代码分析的方法，进行 Web 服务系统调用拦截和文件调用的隔离，从 Java 字节码层次上使得不仅不同用户之间的 Web 服务得到隔离，也保证 Web 服务与系统环境之间得到隔离。而组合服务是由一系列 Web 服务组合而成，只要 Web 服务进行了隔离，组合服务也相应的得到了隔离。（3）系统可用性保证。云计算应用的特点使得系统集成度增强，应用复杂度不可避免地变大，如何保证系统的可用性是其中的重要问题。服务化软件应用引擎将从两个方面来保证系统的高可用性。其一，采用副本策略进行 Web 服务的多副本部署，使得 Web 服务的容错能力提升，同时使得相应的组合服务的可用性提高；其二，使用错误恢复机制，该机制可以使得系统快速的从错误状态中恢复过来，在整体上保证系统对外持续提供服务的能力。 4 当前的系统进展服务资源共享平台 ServiceXchange 已于去年正式上线，访问地址是 www.servicexchange.net ，目前已收集 Web 服务 17261 个，且在不断增加中。个人在线开发环境 MyCloud 和服务软件应用引擎 AppEngine 的原型系统基本实现，目前正在做完善工作。图 9 和图 10 分别从系统调用拦截和文件调用隔离两个方面说明采用服务隔离之后 AppEngine 的性能开销。图 9 水平轴是 Web 服务中待拦截的系统调用行数，垂直轴是部署所用的时间，从图 9 可以看出，由于采图 9 系统调用拦截带来的时延图 10 文件调用隔离带来的时延用了优化方法，随着待拦截系统调用数量的增加，拦截所带来的时延是逐渐减小的，而且最大的时延也在 160ms 以内。图 10 给出了采用文件调用隔离前后系统的性能变化，从图 10 中可以看出，系统响应时间的增长并不大，都小于 10% 。图 1 1 软件设备错误恢复时间图 12 错误恢复时间占总时间比例图 11 和图 12 给出了软件设备采用错误恢复机制后的性能指标，并且与传统的重启式恢复机制进行了对比。它们说明在一定的软件设备错误概率下，我们使用的软件设备错误恢复机制明显比传统的重启式恢复机制花费时间更短，而且随着并发请求量的增大，软件设备错误恢复时间占总调用时间的比例明显比传统的重启式恢复机制增长慢。 5 总结针对传统软件开发中开发人员不得不进行开发工具和运行环境的安装、配置、维护等额外工作的不足，结合面向服务软件的软件生产线系统，本文提出了支持面向服务软件开发与运行的云平台。接着讨论了云平台的体系结构、系统实现以及其中的关键问题。云平台的系统原型已经基本完成。未来我们将加深对云平台关键问题的研究工作，进一步完善系统，提高云平台的性能、可用性以及安全性。参考文献 M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann,"Service-Oriented Computing: State of the Art and Research Challenges," in IEEE Computer. vol. 40 (11), 2007, pp. 64-71. M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A.Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, and M.Zaharia. "Above the clouds: A Berkeley view of cloud computing". Technical Report UCB/EECS-2009-28, EECS Department, University of California, Berkeley, Feb 2009. IBM Smart Business Development and Test Cloud. http://www- 935.ibm.com/services/us/index.wss/offering/ midware/a1030965. M. Hajjat, X. Sun, Y. E. Sung,D. Maltz, S. Rao, K. Sripanidkulchai and M. Tawarmalani, “Cloudward Bound: Planning for Beneficial Migration of Enterprise Applications to the Cloud”. SIGCOMM 2010. H. Sun, X. Liu, X. Li, J. Zeng, Z. Huang, “SOARWare: A Service Oriented Software Production and Running Environment,”Proceedings of the 12th International Asia-Pacific Web Conference(APWeb 2010). SOARProLine. http://www.trustie.net/projects/project/show/SOARProLine. Hailong Sun, Xu Wang, Chao Zhou, Zicheng Huang, Xudong Liu. Early Experience of Building a Cloud Platform for Service Oriented Software Development. IEEE International Conference on Cluster Computing (Cluster 2010) Google App Engine, http://code.google.com/appengine/. Service Exchange, http://www.servicexchange.cn. Apache ServiceMix, http://servicemix.apache.org/home.html. Apache Axis2, http://axis.apache.org/.; 1904 次阅读|0 个评论

Tortoise SVN管理本地代码: 热度 1 zjlcas 2011-5-30 03:51; Tortoise SVN管理本地代码张金龙 jinlongzhang01@gmail.com 什么是Tortoise SVN? TortoiseSVN是一个windows下的文档版本管理的开源软件。用户每次对自己编写的代码进行修改，都会记录在SVN的数据库中。Tortoise SVN能够在设定好的文件夹上添加相应的“对号”，“问号”等标识，标识当前代码的编辑状态，特别是有没有在数据库中保存。对于代码的修改，用户可以添加相应的标注。对于每一次修改，数据库都有详细的记录，从而保证所编写的文档可以回到作者保存过的任何一个版本。这种版本控制策略在软件开发中是极为重要的，当然，在R程序包的开发中也十分重要。用Tortoise SVN管理本地R代码的大体过程如下： 1 下载和安装Tortoise SVN软件，各项均选择默认即可，网址如下 http://tortoisesvn.net/downloads.html 2 在本地硬盘上创建一个新目录，作为数据库的保存文件夹。例如 D:/packages/phylotools 3 右键点击phylotools文件夹，Tortoise SVNCreate a repository here.完成后，打开phylotools文件夹，我们会发现其中新增了一些文件和文件夹。这是版本数据库相应的文件，我们暂且不管。 4 在本地硬盘上创建一个新文件夹，例如在C:/developing/. 点击鼠标右键，选择SVN Checkout。我们看到，developing文件夹下出现了一个phylotools空文件夹，该文件夹上有一个绿色的对号。我们发现，该文件夹是空的，绿色的对号表示，文件夹下的内容已经与数据库中的版本相同了。 5 在该文件夹下创建新文件，或者将之前编写好的代码拷贝到C:/developing/phylotools文件夹下。此时发现每个文件上都被加上了蓝色的问号，这表明这些文件还没有和数据库链接起来。此时我们回到上级目录，C:\packages, 右键点击phylotools文件夹，点击SVN Commit这样，该文件夹下的文件就全部导入数据，并且关联起来了。 6 之后对其中任何代码的修改，均可以提供Comments，并且隔一段时间进行保存。这样以后恢复到以前的版本，就容易多了。而不用隔一段时间备份一下新文件。因为SVN已经帮你把修改信息全部存到数据库里了。; 个人分类: 科研笔记|9749 次阅读|1 个评论

[转载]中国GIS人才生存状况调查报告: cui99515158 2011-5-21 13:08; 一、个人背景调查——GIS 是碗“青春饭”？　　如果不清楚一个人身世，你就无法真正了解一个人。而要了解一个行业的一群人，就更要先从这群人的背景入手，他们的年龄分布如何，性别比例如何，从事不同性质工作的比例如何等等。　　根据网上对GIS 人才年龄分布的调查，GIS 从业人员大都集中在20-30 岁之间，尤其是20-25 岁之间的人群比例甚至超过60%。更为夸张的是，男女从业人员的比例几乎达到5：1,严重失衡。在GIS 人的工作性质调查中，接近半数的人为软件开发人员，其次是数据处理人员，市场营销人员仅为6%，如果将“软件开发”和“技术支持”二者加在一起，可以看成　　技术人员的比例已经超过55%。这说明GIS 行业中，更多的人员是在从事技术性工作，这与IT 行业中编程人员的年龄分布和性别比例基本吻合。正如大多数IT 开发人员自嘲：“IT 是碗“青春饭”，年纪大了靠边站。”难道GIS 也是碗青春饭？二、个人教育调查——考研是否真的那么重要？　　美国学者舒尔茨所创立的“人力资本”理论认为，一个人受教育程度越高，其生产力就越强，对经济增长的贡献也就越大。是否可以理解为，如果GIS 从业人员受高等教育的比例越高，对行业发展的促进就越大？　　从GIS 人才学历调查了解到，GIS 人中有92%的人拥有本科以上学历，其中硕士和博士二者的比例加起来竟然高达35%，这个数字足以令其他行业震惊。目前，很多本科GIS 应届毕业生甚至把考研当作逃避就业的一种方式，尤其是女生，据传某高校一个本科GIS 班的十多名女生竟悉数考研，甚至有人感叹，“是否能读到好的专业并不重要，只要能晚几年找工作就是万幸”。或许这在一定程度上也促使GIS 行业中高学历人群的比例居高不下。然而，不知道目前大多数企业中是否真的青睐这些“高学历”学子们。“考研是否真的那么重要？”或许，在痛下决心之前有必要认真思考一下这个问题。　　考研，拥有高学历，或者在学校所学专业是否对今后工作有较大影响？。根据调查结果显示，有48%的人认为有较大影响，而有39%的人为影响较小，甚至有13%的人认为所学专业根本就是“学难以致用”。看来有相当的一部人对学校所学的专业能否“学以致用”持怀疑态度。既然有人认为学校传授的知识无用，那么，什么样的知识才是GIS 人在工作后所希望给自己“充电”的呢？通过调查了解，计算机方面知识需求最高，其次是与行业应用有关的知识，其它如地理学，测绘与制图等方面的知识也有一定的需求。这无疑与GIS 学科本身的“边缘性”和“交叉性”有关。虽然，目前很多高校已开设的GIS 课程中，大多也设置了诸如计算机，地理、测量、地图等方面的课程，但更多的只是“蜻蜓点水”，学生所学知识远不能满足工作需要。　　此外，GIS 终究是一种工具，是用来分析问题和解决问题的。各个行业，如国土、规划、管线、林业、农业等，需要基于GIS 技术开发行业应用时就需要与本行业的知识结合，尤其对于从事GIS工程开发的人而言，掌握一定的行业知识就十分必要。　　既然从学校出来以后还要学这么多知识才能适应工作，那么考研真的那么重要吗？至少不能成为逃避工作压力的借口吧。三、生活调查——有多少GIS 人有房有车？　　“人本心理学之父"，美国心理学家马斯洛把人的需求分成生理需求、安全需求、社交需求、尊重需求和自我实现需求五大类，依次由较低层次到较高层次。不知中国GIS 人才这个庞大的群体已经需要自我实现，还是仍在生存线上苦苦挣扎？　　按照马斯洛对食物、水、空气和住房等需求都是生理需求的划分，吃饭和住宿应该是最低级别的需求。根据调查结果显示，目前GIS 从业人员中，分别有65%和19%的人需要租房住或者住在单位宿舍，自己买房的人只占到16%，比例实在少得可怜。据猜测，原因可能有两方面，一是参与调查的人群大多集中在25-30 之间岁，由于刚参加工作不久，经济实力不强。二是工资水平整体较低。原因究竟为何，不得而知。　　没有房，就更不用谈私家车了。根据对上下班交通工具的调查，目前仅有3%的人每天自驾车上班、下班。　　另据工作城市调查发现，全国GIS 从业人员中，北京的比例最高，其他上海、武汉、广州等几个大城市相差不大。武汉曾经是中国GIS 最活跃的地区，然而从本次调查结果来看，其比例并不是很高，甚至低于广州和上海。有趣的是，在GIS 人才向往的城市调查中发现，得票最高的是上海，其次是北京和深圳。上海作为东方名城，中国的金融中心，其影响力看见之大。但对于GIS 人，尤其是应届毕业生而言，未必适合自身发展。目前，上海GIS 行业多为行业应用开发，且大多情况下要求较高，偏爱有工作经验的资深开发人员，反而测绘行业展较好。因此，选择工作城市时，应综合多方面的因素全面考虑。四、工作调查——GIS 人都是工作狂？　　根据调查发现，国内GIS 从业者有半数人上的人每天平均工作超过8 小时，有18%的人经常工作超过10 小时。有48%的人需要长期在外地出差，充分说明了GIS 从业者的工作强度和工作性质。　　在对外语要求的调查中发现，有51%的人认为平时工作对外语的要求程度为“一般”，有36%的人认为要求“熟练”，更有13%的人认为“没有要求”，认为要求“熟练”的竟无一人。看来，GIS 行业中对英语的要求因工作而宜，虽然不需要十分精通，但掌握基本熟练的英语还是必要的，尤其是对于那些整天与程序打交道的人。　　在GIS 人才常用的开发语言调查中，排在前三位的依次是VB、VC++和。Net，比例相差不大。排在第四位的ASP，然后是Delphi、JAVA 和PB 各分秋色。而最近一年内对开发语言的需求调查中，。NET 的呼声最高，当之无愧的排在首位。其次是JAVA 和VC++，这也充分表明GIS 技术与网络技术的结合将代表GIS 未来的发展趋势。　　在工作满意度调查中，有49%的人因待遇而感觉不满意，有趣的是，有32%的人因自己的业务知识不足而感到不满意，希望转行的比例却高达11%，都远远超过了很满意的8%。其中的不满是否也跟有84%的人买不起房有关？五、薪资调查——GIS 人对自己的工资满意吗？　　收入满意度调查中，有67%的人对自己的收入水平感觉不满意，25%的人感觉马马虎虎，而感到满意的只占8%。由此可见，有相当大一部分人对自己的收入水平感到失望。　　针对不同职业分别调查后发现，软件开发人员的月收入属于“旱涝保收型”，虽不会“一夜暴富”，但过“中产阶级”的生活足以绰绰有余，月收入大多集中在3000-5000 元左右，部分群体甚至集中在5000-10000 元之间。而市场营销人员“两极分化”严重，“旱者旱死，涝者涝死”，月收入大多集中在2000 元以下和1 万元以上，完全由个人业绩决定收入水平。数据处理人员是调查中整体收入偏低的群体，有71%的人月收入低于3000 元，其中有49%的人甚至低于2000 元。　　为更全面了解GIS 人的收入水平，在进行的年总收入水平调查中，即便加上年终奖、项目提成奖金等各种形式的收入在内，有68%的人年总收入低于5 万元，有23%的人年均收入在5-10 万之间，超过10 万元的到占9% 。由此可看出，大部分GIS 从业人员收入水平偏低，但已有少部分人已经先富了起来。调查发现，大家普遍认为个人工资增长速度缓慢，有74%的人的年收入增长速度低于10%，其中增长缓慢或负增长的高达27%，远远超过其他比例的人数。　　从GIS 人才享受到的福利调查中发现，目前大部分GIS 人只享受到传统的“三险一金”和培训。可喜的是，已经有少部分人已经开始享受境内外旅游、分红和车、房期权奖励了。在这方面，国内GIS 企业应该探索更多的方式提高员工的福利待遇，希望能通过不断完善的福利计划留住人才，以加快自身的发展。六、所在GIS 单位调查——中小民营企业居多？　　调查中发现，目前我国GIS 单位中占比例最高的仍是50 人以下的小公司，已经超过半数。同时，可喜的是有36%的单位规模超过100 人，其中有15%的单位规模甚至超过200 人，这一方面说明我国GIS 发展迅速，很多几年前的小公司也已经得到了快速发展。另一方面也表明参与调查者有相当一部分人属于事业单位，将整个单位规模计算在内。因此，GIS 行业中大部分为中小企业，纯粹以GIS 为主营业务的大公司较少。　　在GIS单位中，有57%的单位属于民营企业，有16%的单位属于高校、院所，各有10%属于国企和政府部门。这也说明我国GIS大多数是由高校、院所等创办的民营企业，并且得到了高校、院所等良好资源的支持，技术水平普遍较好。　　在众多GIS 单位中，其主营业务大多是工程开发或软件研发和销售。从事数据处理的单位比例也达18%，作为行业的特殊群体，近年来发展迅速，值得关注。　　常用的国内GIS 软件调查中，排在首位的SuperMap,占有41%，然后是MapGIS,二者之和达到67%，不愧是国内GIS 软件的二大巨头。有点不解的是，其他国产软件的份额竟达到24%，远远高出其他国产软件许多。究竟是哪几个软件如此受宠，无从获知。　　常用的国外GIS 软件调查发现，ArcGIS 割据半壁江山，甚至超出排在第二位的Mapinfo 一倍还多。其余的国外软件只能“望尘莫及”，发展空间较小。　　目前，GIS 单位对人才需求最多的是资深开发人员，其次是程序员和项目经理。由此也可看出，如果想从事GIS 行业，较强的编程能力才是“通行证”。七、个人职业发展调查——GIS 人都想当领导？　　GIS人才工作稳定程度调查结果显示，将近一半的人跳过槽，说明GIS 人员普遍对目前的境况不满意，其中包括待遇、环境等等，其中有21％的人竟然跳槽次数有三次甚至多于三次，充分说明很大一部分GIS 人员工作不是太稳定，其中有环境的原因，也有内在的原因。　　随着社会的发展，越来越多的人在职业生涯中看重将来的个人发展状况，在影响求职的关键因素调查中，44％的人将个人发展作为求职的关键因素，其次是薪金待遇，占调查总比例的37％。单位所在城市也对GIS 人才求职时有一定影响。　　GIS 人才在选择职业时也多选择高薪职业，调查中有77％的人都趋向于选择高薪职业，即使不稳定也无所谓，从中可以看出收入对GIS 人员来说仍然是一个关键问题。　　GIS 人员将来做什么呢？在个人职业发展方向调查中，68％的人将个人职业发展定位于管理，近四分之一将来做技术，有10％的人选择将来做市场销售或者其他，越来越多的技术开发人员要求更高层次的职业转变，管理人员舒适的工作环境及良好的收入是很多GIS 人才的职业发展方向。虽然技术工作比较累，但由于个人兴趣、收入等原因仍有22％的人选择其作为将来的职业，另外，市场销售人员的高收入也吸引部分GIS 人员加入到销售的行业中去。八、行业调查——目前高校GIS 教育是否得到认可？　　对GIS 行业发展前景的调查中，79％的GIS 人员认为行业是发展的，其中34％的人认为会迅速发展，说明多数人对GIS 行业发展前景充满信心。但也有21％的人对行业发展信心不足，认为会原地踏步。软件也是组成GIS 行业的重要部分。在对国内外GIS 软件差距的调查中，多数人（研发实力48％，技术人才8％）认为国内外在软件的研发实力及技术支持上有很大差距，20％的人认为投入资金的多少也是国内外GIS 软件差距大小的重要因素，20％的人员认为市场因素对国内外GIS 软件差距也有不小的影响。高校是GIS 人才的主要培养地，那么目前国内高校GIS 教育情况如何呢？调查显示，有62％的人对目前国内高校的GIS 教育不认可，31％的人勉强接受，只有7％的人认可。说明绝大多数人对目前GIS 的教育状况不满意。看来，中国GIS 教育状况确实令人担忧，如何提高国内高校的GIS 教育水平，找到适合国内GIS 技术发展和企业需要的培养方式，应该引起有关部门的重视。; 4183 次阅读|0 个评论

消灭程序员需要百年吗？（中）: 热度 5 suxiaolu 2011-4-1 11:04; 然而，时至今日，软件开发不管怎么自动化，总是有一些例外，需要程序员去手工处理。这些例外情况，通常无关乎高精尖，而是些很普通的问题。在八年以前，我还没有接触知识表示和人工智能的时候，这个问题一直在脑中挥之不去。2003年，偶然接触到cyc项目，这又一次彻底颠覆了我的想法，因为这个cyc刚好能作一些看起来很简单，却又非要人工才能处理的事情，而且这些事情并不像看上去那么简单，一个简单的推理常常要调用成千上万条断言。当然cyc并不是一个真正的常识处理系统，它固然是十余年积累的成果，也有很多闪光的思想，但是局限性也很明显。不管怎样，它为我开启了一个全新的视野。人工智能是个很大的领域，其中有很多天才的创见，要理解它的全部内涵，是件艰巨漫长的工作。然而，有一件事情从开始的时候就能得出结论，那就是，如果计算机真的具有了与人类相当的智能，那么必然就不再需要人来为它编程序，那个时候，就是程序员这个职业寿终正寝的时候，当然，整个软件产业也将不复存在。所以，程序员以及软件产业的生存，其实就寄托于那些为数越来越少的，必须人来处理的“例外”情况。我们现在就来关注这些例外情况，因为它们是如此重要，将会决定各位程序员以及产业的命运。软件是什么呢？计算机发展的早期历史上是没有软件的概念的，那时候只有程序，每个用户就是他自己的程序员，编写程序满足他自己的需求。这个时候的程序员，不需要需求调研，不需要划分工作阶段，总之一句话，想怎么干就怎么干，他们也不会考虑复用，因为程序只是他们个人想法的表达，没有想法的时候想也没用，一旦有了想法，两下就写出来了，即使需要借鉴以前的想法，从脑子里调出来比从故纸堆翻出来也快捷得多。也许软件与程序的不同就在于此，软件是做给别人用的，程序是写给自己用的。软件是伴随着不会编程的“业余”用户的产生而出现的。开发软件与写程序第一个不同的地方就是要做需求调研，不管做多简单的软件，都要调研。有的时候，程序员看似没有做，其实是他和用户已经很熟悉，用户的需求早已经都记在脑子里了。用户有需求就表明用户有一些需要计算的问题，这些问题可以由计算机做，当然也可以由人来做，事实上computer最早指的是拿着纸笔或者计算尺工作的计算员们。如果由人来完成计算，用户通常需要告诉计算员计算的公式和流程，然后提供初始数据，如果这位计算员经验丰富的话，有时候不必如此罗嗦，只需要告诉他算什么题目就可以了，计算员自己知道公式和流程，或者即使当时不知道，也可以自己找资料学习。使用计算机就享受不到如此的便利了，计算机不会自己学习查资料，即使硬盘里存有以往的计算程序，它也不会自己去使用，一定要人手工调出来运行。人与计算机的根本差别不在于处理信息的能力，而在于处理信息的主观能动性。自从引入了客户，引入了需求，软件开发开始变得复杂了，最早的客户还比较好应付，他们都是懂一些计算机技术的人，那时候完全不懂的人根本不会想到用计算机做事情。最初的需求都很具体，输入什么，做哪种计算，结果怎么输出，都讲得清清楚楚，所以最初搞需求分析的人都画数据流图，只要数据流清楚了，软件就确定了，今天的程序员就没这么幸运了，工作流程、访问权限、用户体验等等，撞得满头都是包，如果光盯着数据流图的话，什么也做不出来。那时候的分析员和设计师基本上是同一个人，因为没有什么好设计的，就是把功能分解一下，列张表1234写出来，再往后稍微复杂一些，所谓结构化方法，也就是功能多了一些，列表不好使改用层次树。今天的设计师，最惨的时候UML14种图全都画遍，可能也还有没描述清楚的地方。软件出现之后，因为商业的驱动，很快就泡沫一般膨胀起来，各位今天目睹了各种泡沫之后，大概会总结出来一条规律，凡是泡沫一定没有好结果。软件一旦开始膨胀，所需的人工自然不断地加倍，于是以IBM为代表（IBM确实养了不少杰出的科学家，但是养了更多猪头，当科学家和猪头一起研究问题的时候，通常猪头不会变成科学家，而科学家却会变成猪头），采用了工业时代提高效率的不二法则--增加人手，扩大规模，精细分工，流水作业，至于结果嘛，各位学过软件工程第一课的话，恐怕就知道他们的事迹了。扯IBM的糗事看似和我们的主题没多少关系，其实当中有着深刻的联系。我们前面所说的那些可以自动处理的部分，他们用人工都做得很完美，而在那些例外的地方，却几乎无例外地犯错误。那么，例外到底是什么呢？为何总是挥之不去呢？要解决这个问题，我们就需要从更深层次挖掘软件的本质。不管怎么说，软件的核心功能就是计算，那么计算是什么呢？今天互联网上充斥着各种各样的计算，仅仅用数学来概括是不足以涵盖其外延的。在数字系统之外，也存在各种各样的计算，比如模拟计算机的计算，军事上的兵棋推演，商业上的决策方法等等。如果要概括所有这些计算共同的特征，就只有三点：第一，都有一组初始的数据，代表着某个现实的或者抽象的系统在某一时刻的状态；第二，都有一组理论或者公式（或者二者兼具），规定了各个数据如何相互作用；第三，经过计算的过程，最终都得到另一组数据，描述系统在另一时刻可能的状态。如果把第一、第二两条中的要素加在一起，称之为一个模型的话，计算就相当于模型的一次推演。模型推演是人脑最基本的思维方法，人类发明计算机来分担思考的负担，因此计算机当然必须能够担负这样的计算工作。然而计算机并不懂得什么是模型，只是一个执行程序的机器，因此必须由人来将模型程序化，软件简单地说就是程序化了的模型。面向对象的方法其实就是一种模型表示法，而近年更有人提出模型驱动的开发，这都与软件的模型性质密不可分。仅仅认识到软件具有模型的性质还不够，首先，模型本身是复杂的，虽然所有的模型都可以用一组规律加一组数据来概括，但是实际做过系统的人，特别是做行业系统的人都知道，行业知识本身就是复杂的，相互之间常常有说不清道不明的关系，如果不是自己真正理解了这些知识，仅仅以书本和专家言语为基础，做一些表面（形式化）的推理，是几乎一定会出错的。其次，初始数据也不是简单的，今天的系统，数据来源多种多样，精度、可信度各不相同，非结构化的数据常常见到，单是把这些数据转换到适合模型推演的形式，就要费九牛二虎之力。第三，模型代码化本身也不是件轻松的工作，今天的计算环境空前复杂，各种平台，各种支撑系统都要考虑，今天的架构师要掌握的知识比以往任何时候都多。最后，软件虽然以模型为核心，但绝不仅仅是模型，为了让模型进行有用的工作，各种辅助系统也必不可少。（未完待续）; 个人分类: 信息技术|6597 次阅读|8 个评论

[转载]个性张洋,我喜欢:): 热度 2 zlhua 2011-3-10 12:02; 张洋的博客: http://leoo2sk.cnblogs.com/ 摘自博文:OOAD实践之路——真实案例解析OO理论与实践(一) OO自诞生那天起其全部目的就是应用于软件开发实践中，提高软件开发质量。这也是OO存在的全部意义。所以，搞OO和搞数论、搞理论物理不一样，不能脱离应用。搞OO的人应该算是工程师，而不是科学家。两者最大的区别是：科学家可以不考虑自己研究的成果有没有什么应用价值。而工程师不一样，他们要更“势利”，要时刻关心自己研究出的东西有什么应用价值。所以一切OO的研究要以可应用性为向导，不能天马行空夸夸其谈。 OO，即面向对象技术，是一种旨在提高软件质量的综合性技术，其贯穿于软件系统的调研、分析、设计、开发、测试、维护、扩展、升级等整个生命周期，它包含一系列概念、思想、理论、目标、原则、实践、模式、工具、语言等要素，这些要素既相互区别又相互联系，同时从宏观和微观两个角度共同协作，指导和引导开发人员开发出高质量软件，并指导与开发有关的一切过程。 OO并不是孤立的概念或技术，而是一系列要素的复合体，并贯穿于整个软件开发周期。所以，仅仅从某个时间或控件切面切入而应用OO，这样的OO是不完整的，也不可能发挥出其应有的作用。打个比方：如果使用OO的方法和工具进行分析、设计，但是编码过程不能做到OO，就好比制造了一辆豪华的轿车却找头驴拉着走，是不能提高你出行效率的。反过来，如果你是一个C#或Java高手，但分析设计过程不遵循OO，直到编码时才用C#或Java试图OO，这无异于你听说开车能提高出行速度，于是你苦学驾驶技术，并掌握了高超的驾驶本领，但最终却坐在一头驴子上，于是你开始大喊：驾驶技术是骗人的！根本没法用！是啊，驴子上连方向盘、离合器都没有，空有一身驾驶本领又如何发挥出来呢。通过一个实际案例《XX食品公司连锁店在线定料系统》的调研、分析、设计、开发等一系列过程，帮助大家更好的认清OO如何实践，同时澄清一些误会。这个系统是我曾经参与过的实际案例，为了文章需要，将进行一定程度的修改，但一些很关键的东西都会原汁原味保留下来。在整个过程中，请各位不拘泥于具体技术相关问题，而要一直保持一个较高的视端，一睹OO的全貌。第一份说明当这个项目开始时，我们得到的关于我们要做的系统的唯一说明是一页Word文档，这是一份简单的不能再简单的说明。文档里只有一行字：我们需要一个系统，使得全国各地的代理加盟商和连锁店能够通过网络订购原料。另外，我们还知道这是一个食品公司，主营面包、麻花、肉夹馍等食品，在全国各地有多家连锁机构。除此之外，我们一无所知。永远不要和客户谈需求软件开发的第一步是什么？很多人觉得是需求分析。显然这短短的一句说明无法满足我们的要求，于是很自然的，你希望找客户谈话，详细了解情况，然后做出详细的需求分析。于是，你心里有了这么一个算盘：和客户谈话 - 问清所有需求 - 进行需求分析 - 生成需求文档乍看之下，这是很合理的步骤，但是实际上这是不可行的。原因有如下几点。 1.客户不关心系统的所有方面每个开发人员都希望，客户可以清楚的把自己需要的东西的方方面面清楚无误告诉你，然而，这只是一厢情愿罢了。因为，任何一个客户在需要什么东西的时候，只会大致想想要个什么东西，并不会将所有地方都仔细想清楚。 2.有时客户并不清楚自己到底要什么东西有时候，客户并不是很清楚自己想要什么。这不是天方夜谭。很多时候，客户仅仅有一个“想要实现某个目的的动机”，而没有“我需要一个什么系统”这么明确的概念。例如，从上文那个“一句话说明”中，可以看出，我们的客户仅仅是有一个动机：希望有一个系统，能使得他们公司的代理商和加盟店在线定料，至于这是一个什么样的系统，他们并没有明确的概念，更不用说这个系统有什么样具体的需求了。基于以上两点，你是不可能从客户那里问清所有需求的。实际上，就不该和客户谈需求，因为需求从来就不是“客户面”的东西，而是“开发人员面”的东西。需求需要包含方方面面系统需要实现的功能，而客户往往并没有如此精细想过，甚至客户自己对自己想要的东西什么样子都不清晰。面对这种客户，你一本正经往他面前一坐，开发(打开) 笔记本说：“我们谈谈需求吧”，或说“我们进行需求分析吧”，我想客户会立马崩溃，而你也不可能得到你想要的所有东西。作为开发人员，不应该一开始就和客户谈需求，而要先谈特性。很多需求并不需要客户告诉你，开发人员应该能通过常识识别出来，就如没有哪一个买汽车的客户会说：我需要一个辆汽车，要有方向盘，还要有四个轮子。他们通常会说：“我要一辆家用车、要省油、舒适，要至少能坐3个人。”这“家用车”、“至少能坐三个人”就是特性。特性是一些描述，一条特性简要描述了系统的一个客户最关心的核心功能。最(身) 为开发人员，首要任务不是做需求分析，而是帮助用户整理出一份特性列表。这里之所以说“帮助”，是因为很多时候，客户由于自身太关注于某个方面，而漏掉了十分重要的特性，这是你要帮客户想想，并将想到的特性询问客户是否是需要的。如果客户很高兴的说“对！对！”，那么这就是大功一件。所以，在初期阶段，开发人员一定要想客户之所想，急客户之所急，尽快帮客户理清系统有什么特性。所以，正确的过程应该是：询问客户系统都有什么功能 - 写出初期特性列表 - 想想什么遗漏特性，并询问客户 - 查漏补缺生成特性列表下面回到案例。虽然客户的说明只有一句话，我们还是整理出一份初期的特性列表，并将其作为我们向客户展示的第一份工作成果。这份特性列表内容如下： 1.可以将各种原料信息发布到系统上 2.加盟商和连锁店可以通过系统在线定料没错，我们的初期文档只有两项特性。我们把这个给客户看，客户说：“嗯……大约是这个东西吧。”很显然，我们的客户是比较懒的那种，这时，我们有义务引导客户想起更多需要的特性。下面是当时大约对话：开发人员（简称D），客户（简称C） D：你这个加盟商和连锁店是要如何区分呢？ C：我们公司有一个加盟商和连锁店的记录。 D：那么你们是准备将各个加盟商的信息全部录入系统吗？ C：不是，我希望他们能自己注册，就和论坛那种。 D：那么你要如何确认他们的身份，总不能任何人都可以在这个系统注册吧。 C：嗯，我们公司有各个加盟商的详细信息，我们希望他们注册时提供足够的信息，我们进行核对。（于是我们飞快写下一个特性：加盟商和连锁店通过网络进行注册，总店负责人审核后才可以正式使用系统。） D：你们得在后台能发布各种原料的信息吧。 C：嗯，使得。 D：这里有没有什么特别的要求。 C：没有吧…… D：好的，那么你们准备设立几个人负责管理这个系统。 C：就一个人吧，就信息部那个。我们就这一个比较懂计算机的。 D：也就是说不需要有多个人分别管理这个系统？ C：不需要。（写下一个特性：系统需要一个管理员，可以对系统进行管理） D：在你们的加盟商进行定料时，你希望他们怎么操作啊。 C：这个，我没仔细想过…… （看客户对这个地方比较不清晰，我们打开了一个网上书店的网站，给他演示了一下购物车购物的过程） D：你看，你的这个定料过程是不是和这个购物过程很相似，加盟商定料是不是就相当于从总公司购买原料啊。 C：对对！就要这种效果的！（这里要记住，在特性不能直接说清楚时，找相似事物是一个不错的选择。也就是说，说明这个特性像什么，不像什么）（我们又加一条特性：使用购物车功能进行网上定料） D：付钱这一块怎么弄，需要网上支付吗？ C：不了，我们一般又财务专门做钱这一块工作。 D：那买完原料后要不要什么凭证呢？ C：买完后生成一份定料单吧，打印出来，交给财务，财务清算款项，款到账后通知原料那边发货。（又一条特性：定料完成后生成定料单，并可以打印） D：那么关于这些交易，你一定希望能查询吧，你希望怎么查询。 C：哦，这些我们财务那边有专门的财务软件。你这个系统只要能让加盟商定料就行了。到这里谈话基本结束，我们得到如下一张补充过的特性列表： 1.可以将各种原料信息发布到系统上 2.加盟商和连锁店可以通过系统在线定料 3.加盟商和连锁店通过网络进行注册，总店负责人审核后才可以正式使用系统 4.系统需要一个管理员，可以对系统进行管理 5.使用购物车功能进行网上定料 6.定料完成后生成定料单，并可以打印我们将补充后的特性列表给客户看了看，基本得到了认可。到了这里，我们第一步就差不多做完了。但是，我们还是不能马上进入需求分析，因为这之前还有很多事情要做。例如，特性整理，风险规避，这都是后面要讨论的话题。重点总结 1.客户不会想到方方面面。 2.有时客户并不明确自己想要什么东西，而仅仅是有个动机。 3.不要和客户谈需求，要谈特性。 4.开发人员有义务引导和帮助客户挖掘系统的特性。 5.当客户描述不清某个特性时，可以采用找类似事物的方法，说说这个特性像什么，不像什么。 6.在软件开发初期，我们需要首先整理出一张特性列表，而不是做需求分析。三、降低风险风险无处不在在上一篇文章中，我们写出了一张特性列表。然后是不是就可以做需求分析了？很遗憾，还不可以，我们仍有许多工作要做。拿到特性列表后第一件事，就是要尽量降低风险。这里先不长篇大论风险如何如何，我们先做，从做的过程中体会降低风险的涵义。 DRY 这里，首先要引入一个OO原则——DRY。 DRY原则，全称 Don't Repeat Yourself ，指：在系统中，每一个信息或行为片段应该仅仅存在一份，且存在于合适的地方。对于这个原则，很多朋友将其理解为“不要出现重复的代码”，这是很片面的理解。其实，OO本身并不是仅仅关于如何写出优秀的代码，而是关于如何开发出优秀的软件。所以，很多OO原则并不是仅仅代码层面的原则，而是可以应用于整个开发过程的。下面来着重看看这个原则的深层意义，以及讨论其在降低风险中的应用。如何利用DRY降低风险在所有的开发风险中，有一种风险，是由于同一个信息或行为片段分散于系统的不同地方，从而导致重复劳动，并且给修改和维护造成隐患。下面，分别通过例子来描述两种不良后果。 1.重复劳动例如，在特性列表中，如果两个特性本身应该是一个特性，但被误认为是两个不同特性。那么所有基于特性的分析和设计都存在重复劳动，即对同一个特性，做了两遍分析和设计，直到发现重复为止。这个代价是巨大的。 2.修改和维护隐患例如某一代码段完全相似，但是出现在程序的诸多地方。这些相似的代码段一定是完成完全相同的功能，于是有着“同生同灭”的特点，即如果某段代码要修改，一般来说所有这段代码的重复代码都要修改。这就给维护带来很大隐患。 DRY原则正是针对这种风险的一个解决方案。关于DRY在代码中的应用，暂且放下，这里只看它在特性列表整理中的应用。显然，根据DRY原则，要求特性列表中的特性不能具有重复，那么我们再仔细看看我们的特性列表： 1.可以将各种原料信息发布到系统上 2.加盟商和连锁店可以通过系统在线定料 3.加盟商和连锁店通过网络进行注册，总店负责人审核后才可以正式使用系统 4.系统需要一个管理员，可以对系统进行管理 5.使用购物车功能进行网上定料 6.定料完成后生成定料单，并可以打印仔细检查，不难发现2和5其实是在描述一个特性，于是我们将2和5合并成一个新的特性：加盟商和连锁店可以使用购物车功能在线定料。另外，可以看出，“总店负责人”和“管理员”其实是一个概念。整理完后，得到如下新特性列表： 1.可以将各种原料信息发布到系统上 2.加盟商和连锁店可以使用购物车功能在线定料 3.加盟商和连锁店通过网络进行注册，管理员审核后才可以正式使用系统 4.系统需要一个管理员，可以对系统进行管理 5.定料完成后生成定料单，并可以打印再仔细检查，已经没有重复特性。这样，我们就应用DRY原则规避了第一种风险：重复劳动的风险。下面给这种风险下一个定义：重复劳动风险——指由于重复特性的存在，导致对同一特性进行了一遍以上的分析设计过程。最终导致资源浪费，开发效率降低，可能导致无法按时交付。知之为知之不知为不知在使用DRY整理完特性列表后，下一步就是要规避第二种风险：概念模糊。概念模糊风险——指由于开发人员对于某一领域知识不熟悉，而将某一个概念想当然，继而根据这个想当然的结果进行分析设计。如果其想法错误，则会导致系统无法正常使用或无法完成业务既定目的，从而导致返工或项目失败。很明显，一般来说开发人员并不是业务专家。所以对于领域业务不熟悉是很正常的，作为一个合格开发人员，应该谨遵孔老夫子“知之为知之，不知为不知”这一教诲，谨慎负责对待不熟悉的概念，而不能从字面臆想。正确的做法是，首先审视特性列表，对于不熟悉或拿不准的概念，去请教领域专家或客户。下面继续以我们的项目为例。经过对特性列表的分析，我们找出以下疑问或模糊概念： 1.原料（都是什么原料，需要分类么？） 2.加盟商和连锁店（两者有什么区别？定料业务流程一样么？）带着着两个疑问，我们再次拜访了客户。具体交谈就不说了，最后我们得到了如下结果。 1.原料主要就是些炸粉、调料之类的配方需要保密的烹饪原料，没有太特别的，不需分类。 2.加盟商和连锁店不是一个概念，加盟商直属总公司，连锁店可能直属总公司也可能直属某加盟商。加盟商和直属总公司的连锁店直接向总公司定料，不直属的的连锁店向相应加盟商领取原料。连锁店按原价定料，加盟商按照等级分为5级，每级折扣不同。经过以上一番了解，我们基本把模糊概念搞清楚了，并且经过这么一了解，我们的特性列表随之改变： 1.可以将各种原料信息发布到系统上 2.加盟商和连锁店可以使用购物车功能在线定料 3.加盟商和连锁店通过网络进行注册，管理员审核后才可以正式使用系统 4.系统需要一个管理员，可以对系统进行管理 5.定料完成后生成定料单，并可以打印 6.直属连锁店按原价定料，加盟商按照等级分为5级，每级折扣不同我们认为加盟商级别和折扣是很重要的特性，于是把它加到了特性列表里。保证我们能够实现上面我们已经避免了两种风险。现在再来看一种风险。举个例子，如果一个建筑设计师，设计了一座新型别墅，其中有一条特性是：院子里有一个季节调节装置，可以随意将院子里的季节调节为春夏秋冬中任意一个季节。你们认为这个特性怎么样？很酷的创意对不对？但是如果你是别墅的客户，你会这么想？我想你不会和设计师一起为这个非常酷的特性而激动，你会首先问设计师要怎么实现这个功能。没错，可以调节季节的院子是很棒，可以不要忘了，最终我们的别墅是要建筑在实际中的，而实际总会有诸多约束不能让每一个想法变成现实。同上。无论我们设计的东西多么天花乱坠，最终都是要编码实现的。所以，我们要保证所有的特性可以在编码层级上有解决方案。即使我们不能马上知道精确的解决方案，但也要大体知道怎么实现。由此引出了第三种风险：实现能力风险——指由于某项特性不能由具体技术解决带来的风险。这种风险包括两个层面，第一是现有技术完全解决不了。第二是由于开发团队没有解决方案。这种风险可能导致项目延期甚至失败。要规避这种风险，就要逐一审查我们的特性是否可以在现有技术范围内解决。仔细审查后，第一个层面应该是没有问题，所有这6种特性都可以在现有技术内解决。但是对于特性2，我们存在一定问题。因为当时我们都没有设计购物车的经验，一下子不知购物车是如何实现的。为了解决这个问题，要做如下工作。这里要注意，我们在这里可能讨论了很多细节，但是我们要避免提前进入细节。所以，这里讨论的所有细节并不是要进行分析或设计，而仅仅是通过头脑风暴的方式大约有个谱。这个“谱”往往和最终的实现有很大不同，但是至少我们知道这个特性通过某种方式可以实现。在遇到这种风险时，首先要做的是查找相关资料。在查找了一些资料后，我们了解到购物车一般分为Session实现方式和数据库实现方式。这两种方式特点不同，前者支持未登录购物，确不能保存客户购物信息。而后一种又必须登录后才能购物。这里涉及到客户的利益，所以要由客户决定。于是，我们询问了客户，得到的答复是“未登录时要可以定料，而且也要保持定料信息。”这句话有点模糊，但大体可以知道客户的意思，于是我们改写成如下一段话“未登录的用户可以使用购物车，但不能下定料单，登录后才可下单。登录用户可以保持购物车中信息。”我们拿给客户看，并进行了一定描述，客户认同了这个决策。这个确定后，我们就要讨论一下具体解决方案了。我在这里再次说明，以下的讨论不是分析或设计，而仅仅是让我们对棘手的问题更清晰一些，从而心里有个谱，避免实现的时候不知如何是好。在经过一番讨论后，我们都同意的解决方案是“未登录的用户使用Session处理购物车，登录的使用数据库存储购物信息。当用户登录时，如果Session中有将购物信息，将Session中的信息转入数据库。” 这个讨论可以到此为止了。因为我们不需要太精确，我们只要大致心里有个谱就行了。重点总结 1.特性列表完成后，我们首先应该降低风险，而不是做分析或设计。 2.重复特性存在风险。可以用DRY原则处理。 3.存在模糊不清概念的特性存在风险。请仔细询问客户，不要想当然。 4.不知如何实现的特性存在风险。一定要保证对每条特性的实现方式心里大致有个谱，但不需很精确。四、通览全局：避免过早陷入细节的泥沼细节的泥沼现在我们再次将特性列表贴过来： 1.可以将各种原料信息发布到系统上 2.加盟商和连锁店可以使用购物车功能在线定料 3.加盟商和连锁店通过网络进行注册，管理员审核后才可以正式使用系统 4.系统需要一个管理员，可以对系统进行管理 5.定料完成后生成定料单，并可以打印 6.直属连锁店按原价定料，加盟商按照等级分为5级，每级折扣不同我们已经和这则列表折腾很久了，相信很多朋友已经厌倦了，肯定在想：不要在折腾这该死的特性列表了，赶快开始吧。这点我同意。但是要开始做什么？很多朋友可能会说：开始用例分析吧。说实话，用例是好东西，它让我们清晰认识到系统的工作流程，正式因为过于清晰，所以很容易让我们陷入一个细节的泥沼。应该说，从“特性列表”直接到“用例分析”不是一个好注意，因为特性列表关注于功能（Function），而用例关注于系统的业务流（Business Flow），我们从功能直接开始分析系统的细节业务流，这个跨越太大，不利于软件质量的保证。特性是相对分散独立的功能描述，而用例是系统细节，很明显，在这之间应该有一个过渡，而这个过渡，就是一个高层次的，从全局角度对系统的一个概观认识。这个概观认识起到承上启下的作用，既将特性列表映射为一个系统的大概模型，又给系统细节的分析奠定了基础。所以，在系统特性基本确定后，我们首先要从全局给出一个系统的概览，避免落入用例分析这样细节的泥沼。概览系统的有力工具——用例图既然我们要给出一个全局的系统概览，自然就需要有一种方式将其表达出来。显然，仅仅通过说是不理想的，我们需要一种能用于书面表达的工具，而这个工具，就是我们非常熟悉的UML图之一的用例图。很多朋友可能有疑问，上面不是说不进行用例分析吗？怎么这里又画用例图了？因为用例和用例图表述的信息层面完全不同，用例更倾向于细节和业务流的描述，而用例图倾向于整体的描述。下面给出两种工具要表述的信息：用例——表述某个交互操作的动作执行者、用例名称、具体流程过程、例外情况等。用例图——表述系统有哪些执行者、有哪些用例以及执行者于（与）用例、用例于用例之间的关系。很明显，用例更关注于某一个操作的具体流程，所以适合在需求分析中使用；而用例图更关注于整个系统的使用和交互情况，因此能给我们一个系统的概览。下面，我们就使用用例图，从高层次角度看看系统的样子。在这里还要说明的是，随着UML和用例分析技术的发展，提出了业务用例和系统用例的区别，而且用例存在不同的粒度。在进行高层次概览的时候，我们是使用的是一种粒度比较粗的用例图。也许在以后的需求分析中，我们还会使用粒度更细的用例图。通过简要对特性列表的分析，可以画出一张如下的用例图：可以看到，这个用例图并没有太多细节的东西，而仅仅描述了三个信息： 1.系统有哪些用户 2.系统有哪些操作 3.系统和用户有哪些交互。这些，就是我们要的一个系统概观。用例图的验证画完用例图，我们并不是就完事了。因为，要使得用例图真的是全局概观，就一定要保证一点：图中用例覆盖了所有特性。如果不能覆盖所有特性，说明我们的用例图中缺少用例甚至缺少动作执行者。现在我们来验证一下：特性1覆盖于“原料管理”。特性2覆盖于“在线定料”。特性3覆盖于“注册”和“加盟商和连锁店管理”。特性4覆盖于“原料管理”和“加盟商和连锁店管理”。特性5覆盖于“打印定料单”。特性6覆盖于...??? 我们忽然发现一点，这里并没有和折扣有关的东西，那么这个特性没有被用例覆盖。我们知道，如果要实现这个特性，系统中一定要有一定的折扣机制，而一定是有管理员设置的。于是我们增加一个“折扣管理”用例。注意，这里我们可以先不陷入细节，仅仅知道系统有这么一个折扣机制，至于具体怎么实现，到分析设计阶段再讨论。于是，修改后的用例图如下：现在我们可以说：特性6覆盖于“折扣管理”和“在线定料”。好了，这样我们已经确认，用例图的用例覆盖所有特性。重点总结 1.不要过早陷入细节 2.在特性列表到用例分析之间，用该先有一个系统概览，让我们从高层次上审视系统全貌。 3.用例图是实现这种概览的有效方式。 4.用例不要粒度过细，要能反应系统粗粒度操作。 5.最后不要忘了检查图中用例是否覆盖了所有特性。高质量软件的第一要素到目前为止，我们做了很多工作，但是我一直在强调这些都还不是需求分析。在很多人心目中，软件开发的第一件事就是先做需求分析。那么我们为什么不这样做呢？这牵扯到一个关键的问题：我们都希望开发高质量的软件，而本系列文章的重点也是如何通过OO实践开发高质量软件，那么什么是高质量软件？对于这个问题，也许很多人会说，是灵活的、是易于修改和扩展的、是可维护性高的、是用户体验好的、是文档完整的、是代码规范的、是性能处理优秀的……好吧，我承认，这些都是高质量软件必不可少的元素，但是，还有一个更重要的要素，就是：软件必须做客户希望它做的事。你的软件再灵活、编码再规范，客户不关心，客户最关心的是软件是不是完成了他期待的功能，可以做他希望软件做的事。所以，高质量软件的第一要素就是：让软件做客户希望它做的事。知道了这点，就知道为什么第一步不是做需求分析了，因为需求分析的重点不是“让软件做客户希望它做的事”，而是“将需求分解归纳成开发人员容易进行领域分析和设计的信息片段”。所以，需求分析是开发人员面的东西，而不是客户面的东西。作为开发人员，我们要首先站在客户的角度看问题，而不能总是站在开发人员角度，和客户隔着一条河对话。我们要走过去，去河的另一岸。回顾我们的工作现在来总结一下我们目前所做的工作，你会发现，我们所做的全部工作，其目的就是让软件做客户希望它做的事。我们首先总结出特性列表，然后通过分析和询问降低了风险，同时修改了特性列表，最后从做出一张用例图，使得从全局角度对系统进行一个概览。所有这一切，其实都是开发人员在“努力变成客户”，或说努力让自己站在客户的角度看系统，真正了解客户想让希望做什么。因为，最好的理解需求的方式就是理解客户想让系统做什么。我们在哪里？看看地图吧做了这么多工作，是不是有点迷失方向的感觉？似乎我们已经迷失在OO从林中，不知现在身在何处。好的，那我们看看“OO地图”吧，一方面搞清楚我们在什么地方，另一方面看看我们后续有哪些路要走。以上就是实践中的大致开发流程。一般来说，开发大致分为两个阶段：前一阶段我们要站在用户角度，搞清用户想要系统做什么；后一阶段要回到开发人员角度，进行分析、设计、编码、测试等一系列操作。而我们现在正处在两个阶段的交界处。一般在迭代阶段提倡使用迭代与增量的方式进行开发。至于这样有什么好处，以及OO如何于迭代增量方式结合这些问题，我们将在下一篇文章中结合我们的案例详细讨论。重点总结 1.高质量软件的第一要素是：软件做客户希望它做的事。 2.在开发初期，我们要尽量站在客户角度。 3.理解需求的最好方法是明白客户希望软件做什么。 4.开发流程大约分为两个阶段：搞清用户想要系统做什么和迭代开发。再次明晰开发流程在上一篇文章“ OOAD实践之路——真实案例解析OO理论与实践（五、需求分析之前的故事） ”中，我给出了一幅开发流程图：这幅图，加上前几篇文章的内容，给不少朋友留下诸多困惑。如“特性列表不算需求分析吗？”、“用例图怎么跑到需求分析前面去了？没有需求分析哪来的用例图？”为了解开这些困惑，我们应该先把开发流程各个相关概念给明确了。在一般开发流程中，直观上可以分为两个部分：业务阶段和系统阶段。明确这一点非常重要。其中业务阶段主要进行的工作是与计算机无关的，而系统阶段才是和计算机相关的东西。上图中“我们在这里”那道竖线所指的地方，就是业务阶段和系统阶段的分界点。而如果从建模角度分析，整个开发流程分为四个子流程： a）业务建模流程 b）系统建模流程 c）分析设计建模流程 d）部署实施建模流程其中a）属于业务阶段，而b）c）d）均属于系统阶段。业务建模流程的任务就是做业务分析、降低风险和给出系统总体概览模型。系统建模主要就是需求工程。分析设计建模就是我们熟悉的概要设计和详细设计。而部署实施建模是对系统的具体实施建立模型。其中，我们一般所说的“需求”，实际是指“系统需求”，是在b）阶段进行的，所以a）阶段的一切工作，都不能算是需求分析。（当然，如果加一个前缀，说是“业务需求分析”，也是可以的，但是一般在软件工程领域，说“需求分析”是特指“系统需求分析”。）而关于用例图的疑惑，大家应该知道，用例图分为业务用例图和系统用例图，而业务用例图产生于a）流程，这样它们当然会出现在b）流程，也就是需求分析之前。当然，在b）流程中还会出现用例图，这时就是系统用例图了。明白了以上开发流程，我想很多疑惑就自然解开了。所以，其实我们所谓的“需求分析之前的故事”，就是业务建模流程。系统阶段的法宝1：迭代与增量在上文中，我们提到软件过程大体分为业务阶段是系统阶段。在前面几篇文章中，我们已经基本完成业务阶段，下面是进入系统阶段了。不过莫急，在正式进入系统阶段之前，我们有几个重要的、关于系统阶段的话题要聊一下。如果你问我，在系统阶段最应该被牢记的是什么，我会告诉你，是两个词：迭代增量。我们已经知道，系统阶段是在业务阶段的基础上，在计算机领域内进行需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施等一系列环节。但是，如果你想仅施行一遍这个流程，而完成整个系统的话，不好意思，你大致会精神崩溃。如果这个过程仅实施一遍，其实就成了瀑布模型。小系统也许可以，但是稍大点的系统，将会带来严重的后果。我们知道，“软件开发中永远不变的就是变化”，如果采用瀑布模型，反馈将会非常靠后，一直要到部署实施阶段才能看到成果，如果客户要求更改需求或认为当前系统不是他们想要的，那么修改过程会异常惨烈，代价也是巨大的。那么，我们应该如何实施系统阶段开发呢？法宝就是迭代和增量。具体做法是：我们将整个系统分为许多相对独立的“单元”，每次只对一个或少数几个单元实施需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施等一系列过程，一次这样的过程叫做一次迭代，而将一次迭代的成果加入现有成果的过程就叫做增量。这种开发流程的优势是明显的：我们总是能在相对较短的时间内，完成整个系统功能的一个“子集”，这个子集是可以运行的，可以看到效果，所以如果用户不满意，反馈是及时的，修改代价也较小。通过合理的过程控制，变更代价总可以控制在一个可以接受的范围内。在实施迭代增量过程时，要注意一下两点： 1）迭代单元不是环节，而是系统功能的某个子集。如不能说第一次迭代完成需求分析、第二次迭代完成设计……这不叫迭代式开发，这叫里程碑式开发，和迭代有本质区别。 2）每次迭代一定要完整完成需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施这一套环节，产生的成果必须是成品，是可运行、可交付的，是整个系统的一个子集，而不能是一个半成品。系统阶段的法宝2：用例驱动相信，大家或多或少听说过“用例驱动”。那么什么是用例驱动呢？如果你理解了上文的迭代增量过程，就很好理解用例驱动了。上文不是说过，迭代时每次选取一个或少数几个“单元”吗？那么这个“单元”是什么？理论上，什么都可以，只要是对系统合理的划分。但在实践中，人们发现，使用业务用例作为迭代单元是最合适的。为什么呢？其一，业务用例大小适中，规模平均。其二，业务用例大多相互独立性好，适合进行迭代。其三，业务用例能很好反映系统的功能单元。所以，所谓的用例驱动就是以业务用例作为迭代单元进行迭代开发的流程。你看，我们前面做了那么多业务分析，其中成果之一就是业务用例图。而这里，业务用例成了我们进行系统迭代开发的单元和驱动者，所以，软件开发过程不是割裂的，而是相互联系的，不会说上一个阶段过去就过去了，和下一阶段毫无联系。一般，上一阶段的产品总会成为下一阶段的材料。在这里附上一副我自己画的示意图，希望能帮助大家理解本文内容：本文理论讲得多了点，有点枯燥，但是必须讲，因为明白这些是以后进行系统阶段的基础。从下一篇开始，我们回归示例，进入真正的系统阶段了。下一篇，将开始第一轮迭代的起始阶段：需求分析。重点总结 1.软件过程大致可分为业务阶段和系统阶段。 2.业务阶段进行业务建模流程，与计算机领域无关；系统阶段进行系统建模、分析设计建模和部署建模阶段，与计算机相关。 3.系统阶段的两大法宝：迭代式开发与用例驱动。在前面，我们花了六篇文章的篇幅去讨论需求分析之前发生的事情，这些内容看起来枯燥或飘渺，但实际是为真正开始系统的分析、设计和实现进行的必要准备。从这篇开始，将正式进入系统的开发阶段。这一篇文章，将讨论第一轮迭代过程中的需求分析和领域分析环节。选取第一轮迭代要实现的特性回顾前面章节，我们说到，“迭代与增量”和“用例驱动”是系统开发的两大法宝。另外，指出了如下几个要点： 1）迭代单元不是环节，而是系统功能的某个子集。如不能说第一次迭代完成需求分析、第二次迭代完成设计……这不叫迭代式开发，这叫里程碑式开发，和迭代有本质区别。 2）每次迭代一定要完整完成需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施这一套环节，产生的成果必须是成品，是可运行、可交付的，是整个系统的一个子集，而不能是一个半成品。所以，说白了，这第一步就是要从前面得到的特性列表或业务用例分析文档中选取一个或几个特性或业务用例进行实现。（因为特性和业务用例有对等映射关系，所以，从特性列表或业务用例分析文档中选取迭代功能点在理论上是等价的。）这里，我们从特性列表选取特性。那么首先把我们前面完成的特性列表再搬出来：上图就是我们前面得出的特性列表，总共有六个特性。理论上，第一轮选取哪些，总共选取几个，没有明确的规定，但是，在选取特性方面，还是有一定经验可以遵循的，大致有如下原则： 1）就选取个数来说，与迭代周期有关。一般的迭代开发中，一个迭代周期大多选在一周到两周之间，不宜多于两周，所以，每个周期选择的特性要估算能在这个周期内完成。（顺便说一下，在每个周期内，如果发现时间不够，做不完计划，应削减一些特性推入下个周期，切不可延长周期。另外，切不可在周期开始后添加任务。） 2）就选取的特性来说，最好是比较内聚的几个特性。也就是说，每个周期选取的特性，要尽量关联紧密，而和其他周期的特性要尽量耦合度低。 3）就选取顺序来说，因为要求每一个周期都要产生一个可运行的子集系统，所以，最好先选取平台性、基础性、对外依赖弱的特性，再选取功能性、对外依赖强的特性。例如，在这个例子中，如果第一轮迭代选择特性2则不是一个好主意。因为购物车功能要依赖于管理员、加盟商、物料等诸多特性，在后者没有实现之前，很难单独做出一个可运行的购物车子集系统。针对以上原则进行考虑，笔者最终选择3、4和6作为第一轮迭代的特性。至于为什么这样选，我就不再分析，请各位结合我上面提到的三个原则自己思考一下。领域分析在确定迭代特性后，下一步要进行领域分析。领域分析就是针对特性涉及到的实体及实体间的关系进行一个分析，构造出静态领域模型。这里要注意三点：1、领域模型是静态模型；2、领域模型要反映的是实体及实体见得(间的) 静态关系（例如包含等，而调用这类动态关系不该在这里出现）；3、领域模型是比较高视角的模型，其中的实体和最终程序中的实体类未必对应。领域分析的方法有很多，下面我使用一种我总结的领域分析方法。流程如下： step1、提取特性中的名词我们这个迭代周期内涉及的特性是3、4和6，从中可提取出如下名词：加盟商，连锁店，网络，管理员，系统，直属连锁店，原价，等级，折扣。注意，这些名词就是领域实体的候选者。 step2、筛选名词，确定实体不是所有候选名词都是领域中的实体，这一步要对候选者进行筛选。这一步非常重要，也相对难度较高，需要结合经验和前面的客户谈论材料、需求记录等，必要时，要咨询客户或业务专家。下面我们进行筛选。首先，“网络”显然不是领域内的实体，排除。“系统”是对整个产品的总称，也比较明显不是领域实体，排除。排除了两个明显的“干扰项”，下面看几个可疑的家伙，这里，我发现“原价”、“等级”和“折扣”比较可疑。通过对前面材料的回顾分析，基本可以肯定“原价”应为物料的一个属性，难以成为单独的实体，排除。而“折扣”和“等级”是否能成为实体，依赖于后续系统的设计方式，如果将等级单独设计成一个模块，则其应该为一个实体，而若将其设计为加盟商的属性，则不能成为实体。对于这种摸棱两可的候选项，我们姑且保留，并加一个“？”作为后缀。当然，由于前面分析中说明“折扣关联与等级”，所以，仅保留“等级”就可以了，“折扣”可作为其属性。经过上述筛选，获得下列领域实体：加盟商，连锁店，管理员，直属连锁店，等级？。我们不妨先将各个实体画入领域分析图。 step3、确定实体间的关系有了实体，下面要确定各个实体间的关系。如上图所示，管理员比较容易确定，因为它似乎不与任何实体存在静态关系。这里比较纠结的是加盟商、连锁店、直属连锁店和等级四个实体。关于它们间的关系我们不能臆想，要去查阅前面的记录资料或去咨询客户。在 OOAD实践之路——真实案例解析OO理论与实践（三、降低风险）一文中，我们记录了这样一段文字： “加盟商和连锁店不是一个概念，加盟商直属总公司，连锁店可能直属总公司也可能直属某加盟商。加盟商和直属总公司的连锁店直接向总公司定料，不直属的的连锁店向相应加盟商领取原料。连锁店按原价定料，加盟商按照等级分为5级，每级折扣不同。” 从以上文字中，我们提炼出如下关系： 1）加盟商和连锁店没有关系。 2）直属连锁店是连锁店的一种特例。而且应该还有种“非直属连锁店” 3）非直属连锁店可能会属于某个加盟商。 4）等级仅属于加盟商。到这里为止，几个实体间的关系基本清晰了，我们将其表达在领域分析图里：以上就是第一轮迭代的领域分析图了。其中直属连锁店和非直属连锁店都继承于连锁店，而非直属连锁店必定对应一个加盟商，加盟商可以对应零到多个非直属连锁店，每个加盟商有且只有一个对应的等级。 step4、领域分析的优化别觉得完成上述步骤就万事大吉了，虽然我们的领域分析模型已经出来了，但它可靠吗？还有优化的余地吗？万事多思考一点，总是没坏处的。就像刚出厂没经过检测的飞机，你敢坐吗？所以，这里我们要对已经成型的领域分析模型进行一个检测。检测的方法很简单，就是回顾前述工作，逐个点进行验证和确认。当我回顾了特性及初步业务需求后，发现如下两点问题：第一、管理员是否是领域中的实体？要知道，领域中的实体，一定是系统边界内的实体。那这里就要分情况讨论了，如果系统只需要一个管理员，那么系统中就没有对管理员的管理，那么管理员只是系统外部的用户，就不能存在于领域实体中了；如果有多个管理员，并且管理员管理单独成为一个模块，则管理员应放在这里。于是我联系了客户，在确认系统只需要一个管理员后，我毫不犹豫将管理员从领域模型中抹去了。第二、我觉得领域模型抽象层次还有所欠缺。加盟商和连锁店性质很类似，都有注册、都要被审核，其实它们应该继承自某个更高抽象，这里我称其为会员。于是经过思考和修正，得到最终的领域模型如下：这里要注意，领域模型只表示出实体和实体间的静态关系就好了。至于各个实体有哪些属性，有哪些交互，那是后面设计阶段的工作。基于用例的需求分析——编写用例图及用例规约传统的软件工程中，通常使用需求规格说明书进行系统需求分析。而我更喜欢使用用例分析技术。在用例分析阶段，我们要输出两份文档：用例图和用例规约。用例图用于概观上描述需求，用例规约用于对用例的流程进行详细描述，直接作为后续设计、编码及测试的依据。下面进行系统需求分析。 step1、提取特性中的动词上面我们曾使用提取名词法找实体，那么要找用例，就要分析特性中的动词了。废话不多说，我们先提取出特性3、4和6中的动词：注册，审核，使用，管理，定料。因为用例分析中要确定每个用例的Actor，所以，在提取完动词后，要对每个动词赋予其主语，作为其Actor，于是，最终得到的提取列表如下：注册【未注册加盟商和连锁店】，审核【管理员】，使用【注册后的加盟商和连锁店】，管理【管理员】，定料【注册后的加盟商和连锁店】。 step2、动词筛选同样的，不是每个动词都是合法的用例，这里也要对候选动词进行筛选。具体到这里，“使用”是个很泛的名词，不应该成为用例，而“定料”虽是用例，但于这轮迭代的内聚性不高，建议放入后续迭代中。最后得到用例：注册【未注册加盟商和连锁店】，审核【管理员】，管理【管理员】。 step3、用例分析与优化这里的用例有进一步分析的余地，首先，“管理”这个用例粒度太大，很难知道设计和开发，于是应进行分解；其次，“审核”应属于管理的一部分。基于以上两点，将管理分解为“删除会员”、“指定加盟商等级”和“审核会员”，另外，“未注册的加盟商和连锁店”，跟据领域分析，可写作“未注册会员”。另外，这里有几个隐含的用例，就是关于等级的管理，这几个用例从动词分析中是提取不出来了，这取决于特性描述的局限性。我们通过经验和个人的分析，得到关于等级的管理用例。于是，最终用例敲定如下（这里用例命名规则为 uc迭代周期编号.用例编号）： uc1.1 - 注册 actor：未注册会员 uc1.2 - 删除会员 actor：管理员 uc1.3 - 指定加盟商等级 actor：管理员 uc1.4 - 审核会员 actor：管理员 uc1.5 - 添加等级 actor：管理员 uc1.6 - 删除等级 actor：管理员 uc1.7 - 等级信息维护 actor：管理员 step4、给出用例图跟据上述分析，给出用例图如下： step4、编写用例规约需求分析的最后一步，就是为每个用例编写相应的用例规约。用例规约是一种规范化文档，它面向设计开发人员，详细描述了各个用例内部的基本信息、执行流程及例外流程等，必要时可附上相应的活动图。因为用例规约是设计和开发的重要参考文档，所以在编写过程中务必要做到详尽和准确。下面仅给出“注册”这个用例的用例规约作为示例和参考。必要时，可在下端附上活动图：总结在每个迭代周期的初始阶段，当选择完需要迭代的特性后，就可以开始领域分析和需求分析了。本文是先进行领域分析。其实两者并无确定的先后顺序，往往是相辅相成，交叉进行。下一篇文章将进入第一迭代周期的设计阶段。; 个人分类: 快乐学习|2166 次阅读|5 个评论

闲扯知识开发与软件开发: 热度 2 suxiaolu 2011-2-24 12:59; 昨天不经意间又聊起了知识开发与软件开发的话题， NEON 提出的方法论完全就是软件开发的路子，而且集成一大堆工具试图实现这个方法论。如果知识开发真的演变成又一种形式的软件开发，知识表示语言也就相应变成了新一代的编程语言，而失去了它独立存在的价值。不可否认，现有的知识表示语言，当真用来表示知识，是有很多局限性的，这也妨碍了它走向实用。毋庸讳言，现有的知识处理方式不能有效完成常识计算，也不能完全自主地完成自动建模任务，因此实用型大打折扣，达不到人们的预期。这是受当前人工智能研究水平制约的，受对人脑工作机制认识的水平制约的，而这些领域正在迅速发展，这些制约正在逐步减少。如果为了追求尽快达到实用的目的，就把知识表示和知识处理降格为分类体系加规则库加流程描述语言，最后再搞个有推理能力的解释执行器，这就把知识降格为程序，把科学降格为工程。我们不反对把现有的研究成果实用化，但是至少要说清楚名目。关于 NEON 方法论的问题，计划在今后一年当中，详细分析一下，届时敬请大家批评指正。; 个人分类: 知识开发工具|2819 次阅读|2 个评论

关于软件开发的几点看法: 热度 1 dulizhi95 2011-2-18 21:29; 关于软件开发的几点看法就计算机科学专业而言，从学生到老师，从最底层的开发人员到最高层的研究大师，最终的目标还是要开发出软件产品来，故从教学到研究，一切都需围绕这个轴心转。在此，本人以个人经验及思索，谈几点看法，欢迎同行专家指正。曾经在一个课堂上要求学生提问，强调涉及到思路的给我提，涉及到背概念和方法的自己去查，不要问我。当时正值熊猫烧香病毒爆发，有学生要求我向他们详细讲解熊猫烧香病毒，当然，带点刁难之意。记得我的回答要点如下： 1 ，开发者只是一个中专生，说该病毒有多深不可测，需要多高的水平和实力肯定谈不上； 2 ，他在该类型病毒这一点上肯定深入进去了，且具有复杂思路的构思能力，并有某种程度的创造力，智商肯定不低； 3 ，我对病毒没有研究，但你们若能提供该病毒的源代码，我相信自己能很快读通，然后随意修改，并能写出杀毒软件。我举此例是想说明，复杂思路的构思能力，读懂和模仿别人的能力，以及沿某点深入下去的能力，对软件开发人员而言至关重要。这里以个人愚见列举软件开发最难突破的三个方面，也就是说，作为学习者，针对这三个方面去努力培训自己的能力，肯定是正确的方向。 1，综合调试大软件的能力。对一个大而复杂的软件，由多个小组开发出各个模块，每个小组都认为自己做得很好，不会有问题，集成调试时却问题百出，这时极少有人能掌控整个大软件，能把它调试顺畅。 2， bug 问题。有些 bug 非常难解决。 3，性能问题。主要是速度、内存消耗和容量问题。一些有高手开发的成熟软件，往往在这些方面做得相当优美。但用户可能依然对性能不满意，要求显著改进。此时你能不能由发散思维想到别人通常想不到的方法，显著改善性能。大家知道，软件开发往往是谁都会做，一个刚毕业的很普通的学生，到了软件公司后，大体也能搞软件开发，但要做好上述三点，恐非易事。; 2545 次阅读|1 个评论

VC学习经验总结-------我的VC之路: dulizhi95 2010-10-31 09:36; VC 学习经验总结 ------- 我的 VC 之路在美学计算机的中国学生，大都拿了个 Master 就去找工作，我也是如此。倒是面试过几家大公司，可人家与我口语一对话，就基本上准备否了（其实按我的情况，应很适合去包含复杂计算的大公司做算法设计，只是口语不行推销不了自己那也没办法）。后来去一小公司面试，不料碰到一在美同校比我早毕业的女同学，我曾对人称之为整个本地区中国女孩里的第一位。她马上告诉我，她先生在这里负责 VC 组，她先生是我在国内的校友，比我晚几届，但早到美国，他们肯定帮我的忙，录用应该问题不大。老板也是这样说， Chinese 之间好沟通，若录用以后就在他手下做。几天后有电话来通知我去上班。我当时的情况是，复杂思路的构思能力很强大，用 C 编写调试很复杂的程序也很溜，但 VC 的确一窍不通。在我那位校友老弟（我称他为师傅）手下做 VC ，主要是几个软件的维护，每个软件约十万条语句大小。后来读通了那几个程序后，我发现老外的面向对象程序写得真漂亮、精炼！而我自己的面向对象程序往往按面向过程来写。刚开始，师傅几乎是一步一步教我学 VC 的，很快要我加一些小功能，告诉我在什么地方加代码，在什么地方取数据，将数据传给谁等。当然我进展飞快是自然的。但，半年之内，我一直离不开师傅，关键是出了较麻烦的 Bug 搞不动。最后多次到这样的地步：我说肯定不是我的问题，是系统的问题，我的程序不可能有问题，但师傅帮我一调，结果还是我的问题！在师傅手下做一直很轻松愉快，也很自由，我是一有问题就跑到他办公室去找他，由于互相理解对方都极快，随后往往又谈笑一番，以至于旁边办公室的老美看到这两个老中这么快乐，都投来羡慕的目光。不过，也有过一次与师傅大吵的经历。那天他不知怎么心情不好，很粗暴地训斥我。尽管师傅有恩于我，且是我的顶头上级，但杜某从来受不得气，当即以粗暴和高声与他对干，他那位美丽出众的太太就在旁边办公室，同学近一年她当然很了解我：她先生 VC 厉害，但吵架绝不是我的对手。她赶忙跑过来，也不作声，只是微笑着望着我们俩，两个大男人立马熄了火。这是唯一一次受师傅训斥，他当然也明白，这样进展快的徒弟是不应挨训的。总之，在这个小公司，我达到了能将 VC 掌控自如的地步，以及：别人写的 VC 程序，十万条语句以上，我不要任何文档及注释行，任何介绍，硬读源代码，就能将软件结构，数据结构，数据库，算法思路，全部读通并推出来，而且时间很快，然后大动干戈，想怎么改就怎么改。在此，向师傅夫妇表示永远的怀念并致祝福！后来在国内一公司，有一软件，十万条语句大小，市场很火（加硬件后），我去后要我：解决 Bug 问题；加功能；改进性能。原开发组已有几人跳槽，没有文档，非结构化维护，但集成汇总的那位还在公司，在另一部门。我们的部门经理告诉我：先请那位汇总的来跟我详细讲一遍，再给我三个月的时间熟悉软件，再开始正式改。我当时根本不知道软件啥样，只是心想，什么不得了的软件我需要花三个月才能读懂。故当即脱口而出，讲解没有必要，只要他将运行环境给我装好，我硬读源代码就可以了，我最多三个星期就足够了（后只用了一个星期）。我举此例是想说明，读懂别人程序的能力是多么的重要，亦是自我培训的目标。这里不可能详细谈 VC ，只给几点经验小结： 1，首先，思路是核心的核心，有了思路能力一切都好办，否则概念背的再多也没用。 2， VC 几个主要类之间的关系，各个类之间复杂的数据传递，是基础，经常碰到一些高年级的学生 C++ 的这些都有困难。前面说的那个国内公司，一个刚毕业的研究生，叫他在程序中加一简单的小功能，他不知在哪里动手，长时间就是加不进。关键是不知在正确的地方取数据，并传递数据。 3，学会读懂别人的程序是重中之重，有了这个能力就有了一切，关键是先集中精力读懂一两个较好的范例。 4， VC 的底层系统代码是可见的，能读懂它，并使他为你所用，是提高 VC 功力的重要一步。 5，功力不强时，遇到大而复杂的程序，关键是 Bug 难处理，这时候，有一个好的师傅是非常必要的。; 个人分类: 未分类|5238 次阅读|4 个评论

试论围棋软件开发与NP问题: 热度 1 dulizhi95 2010-9-7 07:47; 试论围棋软件开发与 NP 问题有网友给本人留言，建议我开发一个围棋软件，说那不就一切都证明了吗？此建议非常好，但要做好还有诸多困难，且就算做好了，也不意味 NP 问题的解决。下围棋属敌对搜索，是极大极小搜索加剪枝问题中的一种。问题在于，它的分支数非常大，也就是可选的点很多，因而计算深度就只能很浅了，否则计算量和储存量都会大得惊人。不仅如此，它的状态值量化非常困难，从而在进行优劣选择以及剪枝时，非常难把握。因此，迄今最好的围棋软件只能达到业余二段的水平，与专业高段当然是相差十万八千里。人能达到专业强九段的水平，我们不妨假定此水平极高。由此就产生了如下问题： 1 ，围棋是 NP 吗？ 2 ，围棋是 NPC 吗？ 3 ，此问题能在多项式内解决吗？注意到强九段，显然，不能认为强九段的思维能力和记忆能力能满足指数型。我们不妨设想人类能出现这样顶级的围棋高手，他下棋就能达到最优，也就是说能在多项式时间内完成判断计算。这就意味着，一个明显的指数型搜索问题，有人却可在多项式内完成。他是如何办到的呢？回答只能是：充分研究后充分的知识积累以及复杂的关联信息的充分把握！由此，可以得到解决 NP 问题的某些启发。从逻辑上可以判断，人能做到的，软件也应能做到，且不会增加计算量和储存量。自从我的论文在网上公布后，收到过一些电子邮件和反馈信息，主要是要我寄正式版的运行程序，有的甚至表示愿意将自己的成果跟我交流。也有的规劝我不要搞了，说那极难特难，不可能搞出来。还有网友说我在 arxiv 上的那篇论文隐藏了核心内容没有公布，因而看不懂。我这里要说明的是，我在 arxiv 上的那篇文章公布了全部的核心内容，包括完整的逻辑思维线条，根本没有什么不愿公布的东西。我最害怕碰到这样的人，用常识性东西来规劝我：你可能不理解， NP 是非常顶级的世界难题，所以你不可能搞出来；或者： Hamilton 环尽管是 NP 完全的，但它在大部分情况下很容易算，所以你的程序不能说明问题 ----- 此点我当然知情，且我在论文中早已提到过。至于它到底是怎么个容易法、分布法，我掌握得很清楚，显然无须被规劝。我也害怕碰到这样的人，真的高手或故作高手：我的时间非常宝贵，不愿意浪费时间看你的论文，因为它不可能对。问题是，某些主动给我发邮件或给我博客留言的人，也有这个意思，我并没有招你呀？我最希望碰到这样的人，稍花点时间看我的论文，之后产生如下结果： 1 ，表示肯定或表示自己无法确定； 2 ，从根本上否定并指出问题所在； 3 ，指出在哪个地方肯定有问题； 4 ，指出在哪个地方可能会出问题。最后，并给我解释说明的权利。我断言，人世间不存在这样的智商：能在较短时间内，做到第 2 点或第 3 点！再次强调，我在 arxiv 上的那篇文章就是全部，完全可以得到上述结果！此外，我显然没有兴趣从 NP 理论知识，从算法思维能力的角度得到帮助或指点，但我希望能从英文论文写作的经验，从论文投稿的经验，以及在我论文的收尾工作上得到实质性指点和帮助，甚至包括重新组织论文结构和语言表达。当然，若是有实质价值的帮助，有较明显的工作量，那就不是帮助了，而是合作（ Share ），也就是说，我不能让人白帮忙。前些时，我对论文作了一些细节添加和修改，并在论文后面补了一段简单的概要：第一要点，第二要点，第三要点，连起来就是证明。若要否定我，须否定其中任何一个要点。将论文先后寄到两国际顶级期刊，效果依然不行。其中一个初筛关倒是过了，到了一国际知名的大牛手中，那家伙又是不给理由就拒了。该期刊在给我拒绝信时，要我有什么意见，直接 kindly 回复该大牛。在此特请教经验丰富的专家们，是否有抗辩的可能，怎样 kindly 抗辩？; 个人分类: 未分类|5012 次阅读|5 个评论

软件开发项目失败的原因（100110）: ymin 2010-1-10 16:27; 软件开发项目失败的原因（100110）闵应骅在IEEE出版物和国外出版的书中都能发现关于软件开发项目失败的报道和原因分析。但是，在国内，无论是新闻、杂志和书籍中，我没有看到过关于软件开发失败的报道、论述和分析。我记得，我在《中国传媒科技》2005年前进中的可信计算IV---软件可靠性是个大问题里面曾经谈了这个问题，但无人理会。其实，就我自己经历的、听到的、看到的这样的事例多得很。我们的新闻少有负面报道。计算机系统、软件系统成功的报道经常有，振奋人心。讨厌那些负面报道，让人生气，外行人看了也不高兴。有教训自己吸取就算了。其实，这是一种误解。项目失败是花钱买教训。如果只有某一位负责人花钱买了教训，他自己可能不会再犯，可新人一上来，他可能又要花钱，重新买教训。所以，花钱买的教训应该共享，让大家都长见识。最近，智利人在一个科研课题的支持下，在CACM发表一篇文章Why did your project fail?他们收到304个调查问卷，对88个问题回答完全的有235个，涉及失败项目70个。其中49个是内部开发项目，21个是外部付钱的项目。其中美国28个，澳大利亚9个，智利33个。他们分析失败原因及其占失败项目的百分比如下。（一般地，失败原因有多个）交付日期影响了开发过程 92.9% 项目难度被低估 81.4% 风险在项目中未予重新评估、控制和管理 75.7% 未给夜班加班费 74.3% 交付决定未带适当的需求信息 72.9% 项目成员合作不愉快 72.9% 用户未参与项目计划预计 71.4% 风险未列入项目计划中 70.0% 更改控制未有效管理和处理 70.0% 用户有不现实的预期 68.6% 过程没有在每一步完成时进行评估 67.1% 项目开发方法不适当 65.7% 过紧的计划影响组员积极性 65.7% 项目进行中问题规模有变化 64.3% 计划对组员生命有负面影响 62.9% 为了完成任务，项目组有不适当人员加入 61.4% 为了赶任务，新增人员太晚 61.4% 用户为需求收集的时间太少 60.0%; 个人分类: 计算机|6487 次阅读|2 个评论

更多...

帐号		自动登录	找回密码
密码			注册

关闭 安全验证

标签: 软件开发

相关帖子

相关日志

关闭安全验证