标签: 软件开发

初学者的SDN学习之路

SDNLAB123 2015-6-25 13:26

Software Defined Network 顾名思义软件定义网络，可以简单地分为网络和软件两个部分：软件和网络。此外，通过使用OpenFlow协议来实现SDN是一种较为普遍的方式，所以本篇将从软件和网络以及OpenFlow三个方面进行介绍。在研究SDN的研究者之中，有相当大比例的网络工程师，他们了解网络，精通网络，然而却并不了解软件开发。除此之外，还有很大比例的研究者是软件工程师，他们软件开发能力出色，然而并不了解网络运作的机制，在接触SDN之前，他们的范围仅仅只是应用层，底层的东西交给全交给主机的协议栈了。还有一部分同学是像我这样，通信工程出身，学的是物理层的编码解码，误码率，电磁波。不像计算机专业那些学生一样，学习各种语言，操弄各种编译器，混迹于github这种全球最大的男性交友网站。剩下最后一种就是又懂网络，又懂编程。这种人，我一般称之为老师，是用来请教问题的，比如地球-某某老师。一般的,他们不屑于看到这种文章，太low。 本篇主要的目标用户是对网络和软件开发都不太了解，或者网络和编程开发只擅长一种的研究者。由于我也是一个初学者，所以仅当做经验分享吧。如有表达不对的地方，敬请指出，万分感谢。 网络 软件定义网络，如果不了解网络，那如何去定义一个你不了解的东西？如果不知道网络中存在的问题，如何使用SDN来改善？所以网络知识至关重要。然而作为一个初学者，并不需要网络各个方面都精通，也做不到，仅需学习基础知识，并选择一个研究场景即可。 计算机网络 学习网络的必修课是计算机网络。计算机网络讲述的是计算机网络的运作机制，都是极其基础重要的知识。谢希仁前辈的《计算机网络》是从底层往上层介绍，从物理层的hub到数据层的网桥和交换机，到网络层的路由器，最后讲到TCP/UDP的传输层，止于应用层，适合有通信背景的学习者。《计算机网络：自顶向下方法》则是从另一个角度出发，从应用层向下介绍，摆脱了物理层的枯燥，这样的思路更适合学习计算机出门的学习者。《CCNA学习指南》也是推荐的书籍之一，前部分内容讲解计算机网络非常简单明了，更贴近于真实网络规划，可以当做计算机网络的进阶书籍阅读。 学习完计算机网络之后，学习者应该懂得二层交换、三层路由，了解到OSI七层协议栈，也了解了TCP/IP，ARP,ICMP,DNS,DHCP。作为检验标准，读者可以尝试介绍一个客户端主机和跨网段的服务器进行通信的流程。 关于网络协议，只需了解主要的一两种，其他了解其作用即可，因为协议实在太多了，没有必要学完。RIP、BGP、OSPF和IS-IS需要了解。如果研究的课题与路由协议相关，则可详细学习，初期不建议深入学习。学习成果检验是对比路由协议的差异，如RIP的广播路由信息和OSPF的告知邻居。 ARP,ICMP ，DNS,DHCP这几种功能型报文非常重要，均需了解其工作流程，具体的报文格式，可适当了解关键字段。项目需要时再深入研究。 TCP/UDP 的差别需要牢记，适合的应用场景也许了解。关于TCP的状态机，建议尝试记忆，TCP的三次握手建立连接，四次握手释放连接是面试高频题。 应用层的仅需了解若干常用协议如SMTP,POP3，HTTP及其对应的传输层的端口号即可。 网络场景 当学习了基础的网络知识，学习者已经具备了一定知识储备，对网络也有了基础的了解。然而现网之复杂，并不是看了一本《计算机网络》就可以了解的。网路可以按照规模分为局域网，城域网，广域网，也可以按照功能划分成接入网，传输网和核心网。当然按照场景划分就更多了。云计算网络的典型场景数据中心网络是目前研究的热门领域。以校园网为代表的园区网也是较为常见的SDN应用部署场景。跨数据中心的互连互通、WAN的研究则是研究的另一个大方向。 选择一个自己喜欢的应用场景，进行深入研究，并根据需求学习相关知识，会大大提高学习的效率。比如我选择学习数据中心网络，所以我需要学习一些云计算的知识，需要了解数据中心中的网络架构。我推荐《腾云：云计算和大数据时代的网络技术揭秘》作为云计算网络知识的科普书籍。书中介绍了很多有用的知识，包括云计算的起源，云计算和网络的关系，网络安全，以及数据中心网络中的一些关键网络技术。读完你应该了解到什么是TOR和EOR，知道了刀片服务器，了解到VN-TAG是用来标识虚拟机到TOR的流量的，了解到VXLAN和NVGRE的作用，了解到交换机还可以组装的，除了OVS之外还有NEXUS 1000v等产品。读完这本书，能对现网的一些技术，以及产品有一些科普性质的了解，对后续深入学习研究有很大帮助。 相信有了前面计算机网络知识作为铺垫，再选定一个特定的研究场景，网络方面的学习已经不成问题。 软件开发 软件开发是SDN学习中另一个重要方面，这方面我同样不是行家，我也是新手，所以以下言论仅当做自己的经验介绍。 选择一门语言，选择一个控制器 根据自己的喜好，选择一门语言，然后根据语言，选择一个对应的控制器，这是开发的第一步。如我自己，在折腾了C/C++,Java,Python之后，最终还是皈依到了Python大法的旗下。根据Python语言，我选择了由Python语言写的POX。POX无需安装，直接可以运行。同时，POX代码简单，初学者只需阅读pox/forwarding文件夹下的代码即可。 根据我们已有的网络知识，我们基本可以看懂pox/forwarding文件夹下的程序逻辑。以l2_learning.py为例，该文件完成了一个简单的二层交换的应用，其逻辑为：记录MAC地址和Port的对应关系，转发时，查询MactoPort表，若查询成功，则转发，若失败则泛洪。后来RYU出现了，封装更好的，性能更好的RYU成为了我的首选。 在编程的过程中，需要进行程序设计，其中设计的算法以及数据结构的知识在这里不多介绍，有兴趣的读者可以自行学习。 以项目为导向，先写起来 阅读源码需要有明确的目的性。最开始可以先尝试读一些简单的如Simple switch之类的代码，掌握一些简单的API的使用，理解基础的内容，然后再进行深入的源码阅读。 在进一步学习SDN开发时，建议以项目为导向，先写起来，在尝试中去解决问题。在写的过程中遇到问题再去查看源码找关键点，如此一来学习非常有效率，且学到的东西很快就可以用上，学习效果好。特别是在OpenFlow协议已经经过多个版本的扩张，目前内容已经非常多的情况下，选择性学习能帮助你降低学习的压力，提高学习的效率。 时间充裕的情况下，你可以选择好好阅读那些你认为重要的代码。比我在经历了多个APP开发之后，我觉得我需要好好了解一下RYU的内部机制了。所以我花了三天，把从底层socket到协议解析，到事件分发到handler注册的代码认真看了一遍，收益颇多。 学会Debug 写程序容易，调程序难。掌握正确的调试方法能大大提高开发的效率。 为提高调试的效率，在程序设计的时候就需要非常注意。写程序时需要注意程序的设计，比如成端的逻辑尽可能写成函数；一个函数不得过长，最好别超过一个屏幕的行数；尽可能模块化地编程，可以提高代码的重用率，将错误域缩小到某模块，某函数，容易定位错误。在调试的过程中，控制变量的思维方式可以大大提升效率。其他编码风格方面的要求，建议按照google的PEP8风格进行代码编写。 对操作系统的熟悉和理解也将大大提高开发效率。熟悉Linux的基本操作是必须的，如果不清楚，你可能需要自学一下linux和shell。在调试的过程中，错误显示一般是英文，所以能读懂错误信息，并学会谷歌是一项必备的技能。一般的问题谷歌都可以解决。另外，加几个SDN的技术群也是提高DEBUG效率的一个重要手段。 关于开发的建议还有，构建一套适合自己的、高效的开发环境，以及做好版本控制。比如我自己，我只用sublime编译器，编译运行和调试都直接在终端中进行。版本控制使用git。版本控制的重要性不许赘述，详情谷歌。 OpenFlow 目前应用最广泛的SDN实现协议:OpenFlow,是学习SDN中必须要学的核心内容。在设计一个SDN的应用时，需要以下的步骤： § 明确网络应用的逻辑 § 明确对应的操作所采用的OpenFlow报文 § 根据应用逻辑以及OpenFlow协议进行编程开发 比如一个简单的二层交换机，首先我们明确了他的运作机理是MAC学习和转发，然后明确转发所需要使用的OpenFlow报文是:packet\_out和Flow\_mod，最后根据应用逻辑以及OpenFlow协议对应的报文，进行编程开发。 所以我们可以知道OpenFlow在SDN应用中的重要性。 OpenFlow 经过这几年的发展已经从1.0版本发展到了1.5版本，初学者在学习的时候需要注意顺序。建议先学习OF1.0版本，再学习OF1.3版本，更高版本根据需要进行学习。 OpenFlow1.0 版本是OpenFlow火起来时的第一个版本，其内容并不多，Match域仅有12个字段，动作种类也不多，同时也是单流表。对于初学者而言，学习1.0版本可以大大降低学习压力，掌握OpenFlow核心内容。在正确理解SDN，以及可以使用OpenFlow1.0协议开发SDN应用之后，可尝试学习1.3版本协议。1.3版本较1.0版本内容大幅增加。经过几个版本的迭代，OpenFlow1.3版本协议已经有了三种表： § flow table § group table § meter table 动作种类也得到了拓展，多流表的概念也变得成熟，Match匹配域已经多达几十个，所以这时OpenFlow已经将Match域分成几类,并以OXM的形式呈现出来。多控制器写作的概念在1.3版本中也已经相当成熟。 OpenFlow1.3 版本为SDN应用开发提供了很多便捷，开发人员可以利用多流表，设计更多复杂的应用逻辑。作为一个比较稳定的版本，1.3版本成为继1.0版本之后控制器支持最多的版本，所以此版本是SDN学习者应该要学习的。 总结 SDN 学习与其他研究方向相比，要求较高，需要了解软件开发以及网络，学习起来，并不太容易。同样作为初学者，我从大三开始接触，有幸有学长带着入门，再后来由于网络知识的缺陷，一度陷入不知道做什么的状态。恶补了网络知识之后，才慢慢走上正轨。然后最近我又遇到了编程上的难题，急需恶补，急需努力提升自己的开发能力。本篇学习笔记，是几年来学习的粗略总结，希望对SDN初学者有帮助。 最后，兴趣是最好的老师，如果你喜欢SDN这个方向，就会学得很快，比如最近一个学弟兼老乡北邮-毛健炜就进步飞快。如果在学习的过程中没有成就感，没有乐趣，也可以试试别的方向，做自己喜欢的事最重要。 本文转载自 SDNLAB ，原文地址： http://www.sdnlab.com/12184.html

个人分类: 技术交流|2392 次阅读|0 个评论

一个计算机硕士的思考

热度 10 xdcaxy2013 2014-10-30 15:43

五年前的暑假，当我领取到大学通知书的那一刻，我就和计算机行业开始结缘，现在算来已经有五年多了，身在这行，也深深的了解计算机专业的同学从本科到硕士的成长经历，今天也想讲讲这方面的问题。 首先来看看计算机专业的学生就业面总体可以分为：（1）研究型的，比如大学，研究院。以理论研究为主。（2）实用型的，偏硬件类的，比如联想，小米 （3）偏通信类的，比如华为，中兴，思科这样的（4）偏软件类的，百度，阿里，腾讯（BAT）这样的。（5）偏运维，比如移动，联通等等。（6）其它类。如各大银行软件开发中心，医院的信息中心，公务员等等。 综上可看，计算机专业的学生可谓很幸福，就业面如此之广。可是为什么我们的大学生，研究生依旧是一片的迷茫呢？下面来谈谈我的看法： 我记得高考完，当时填写志愿后，谈起大学计算机专业，那就是从大一军训完开始就一直在实验室待，解决国家重大专题，个个五笔，网站玩的流转。四年出来只要涉及计算机的东西什么都会。入学军训结束后，开始上课了，大家手头到手的书是《高数》，《工程制图》，《英语》等等。一开始进入大学的新鲜感，准备好好学专业课的，劲头没了，于是很多同学开始迷茫大学生活。开始逃课，睡觉，恋爱，考试只求过。大一大二的两年基础课程学习，到大三很多人早已经没有了学习专业课的动力，这个时候很多人开始准备报辅导班，考研的时候，我们的专业课开始了，依旧是比较理论化，偏向于基础性的研究。这个时候我们的本科生会非常的失望，感觉四年白读了，计算机程序没多少会写，自己甚至连组装电脑都不会。然后就到了要毕业滚蛋的境地了。读研以后亦是如此，每天面对论文，会觉得所学东西用处不大，太过理论，出去甚至不如高中生会编网页。。。 造成这样的局面不能只批评我们的高等教育，学生自己也有很大毛病，还是不能正确的理解大学的精神含义，如果我们计算机专业的大学生们，在高考完那两个月开始报个培训班或者自己每天开始编写代码，那么在进入大学军训以前，就至少会初入编程行，懂得最基础的代码，例如C。进入大学后利用每个寒假暑假申请进去企业实习，参与项目，还有实习工资可以拿，也不会到大四毕业很多人连毕业答辩系统都自己写不了，而现实中我们的同学暑假寒假多数在家无所事事，或者打工也是去饭店当服务生这样的工作。等到毕业地时候很多人又是想考公务员这些，于是拿起《申论》这些，造成了计算机专业很多毕业生计算机素养的缺乏。当然考公务员这些本身没错，只是就专业培养而言是失败的。 学校的理论，比如算法，比如软件工程这样的东西首先是非常的有用的，但是我们的大学生由于缺乏实践，往往把精华当成了垃圾，上课睡觉，玩手机，逃课普遍化。我在想我们的大学能否在高考完之后就开始为我们的准大学生引路，让他们充分利用好寒假暑假，利用好自己的四年青春年华，在毕业的时候，真正掌握技能，把我们的很多与数学关系不大的专业课程，比如 java语言，数据库，工程实践这些非常实用又不难的课程提前到大一 ，在他们做项目吃了亏之后，再开软件工程，算法这样的理论指导性的课程，这个时候，他们会感觉到那些理论的重要性，这样原有课程体系没有变化，对学生也会更好。这是我自己的一点思考，因为我也是在企业实习中深深的感受到了算法和软件思想的重要性，才有了上面的一点感悟，记录下来。

6584 次阅读|14 个评论

Visual Studio项目属性的一些配置项的总结

T573029173 2014-10-11 15:10

【此文为网络资料整理版】 这几天刚好要做一个决策支持系统软件的框架搭建，看到网上一些较好的资料整理了下，给大家分享。 一、 Visual Studio 项目的文件组织方式 VC6.0 之后的 VC (VS) 系列使用解决方案 (Solution) 来替代原来的工作空间，用于组织和管理多个相关的项目 (Project) 。 VS 中的每个管理器 ( 解决方案或项目 ) 都会对应一个总的文件夹，这个管理器文件夹下存放本管理器的配置文件以及子管理器。以 C# 项目为例，解决方案管理器总文件夹下包含解决方案配置文件 *.sln 和项目子管理器文件夹，而项目子管理器文件夹下包含 C# 源文件 *.cs 、项目配置文件 *.csproj 、 Properties 属性文件夹、 obj 文件夹和 bin 文件夹。其中 obj 和 bin 文件夹下各包含 debug 和 release 两个文件夹。 obj 文件夹下存放中间编译结果， bin 文件夹下存放最终生成的 exe 或 dll 文件。 二、常用项目属性和系统默认配置变量 通常程序开发步骤包括编辑程序、编译程序、装配链接程序、程序调试测试、安装部署。表 1 给出了程序开发过程中常用的系统变量名和意义： 表 1 项目配置常用的系统变量名和意义 图 1 是某一个工程设置的例子，下面的案例中是以新建一个 MyProject 的项目为例： 图 1 注意：从上图可以看出， TargetDir 指目标目录，是一个目录。而 TargetPath 是目标路径，包括具体的文件名。 2.1 常规 — 输出目录 项目属性的“常规”栏目中“输出目录 (OutDir) ”的 作用是给 $(OutDir) 系统变量赋值，其 默认属性值为 $(SolutionDir)$(ConfigurationName) ， $(SolutionDir) 表示解决方案目录， $(ConfigurationName) 的值为 debug 或 release 。启动编译后会在解决方案文件夹下建立 debug 文件夹。 也就是说默认情况下的输出目录是在解决方案目录下的 debug 或 release 文件夹下，当然这是针对 C++ 型项目而言， C# 型项目不一样。 2.2 常规 — 中间目录 项目属性的“常规”栏目中，“中间目录 (IntDir) ”的作用是存储链接器所需的输入文件，默认属性为 $(ProjectDir)$(ConfigurationName) ，编译后会在 MyProject 项目文件夹下建立一个 debug 文件夹，并在该文件夹下生成 MyProject.obj 二进制文件。 2.3 链接器 — 常规 — 输出文件 项目属性的“链接器”栏目下，“常规”选项下，“输出文件”默认属性为 $(OutDir) \ $(ProjectName).exe ，其中 $(OutDir) 指的是输出目录，启动链接后，在输出目录下生成 MyProject.exe 文件。 $(TargetDir) 的值是由“输出文件”指定的目录决定的。也就是链接器最后生成的 *.exe 文件所在位置。 图 2 “ 输出目录 ”和“ 输出文件 ”两个属性对应的目录默认情况下是一样的，这样用着方便。如果两个不一样，则链接器所需的 *.ilk 和 *.pdb 等中间文件在“ 输出目录” ，而最终生成的 exe 文件在“ 输出文件 ”属性设置的目录中。 2.4 调试 — 命令 项目的“输出目录”属性值决定着系统变量 $(OutDir) 的值，而项目的“输出文件”的属性值决定着 $(TargetDir) 和 $(TargetPath) 的值。 程序调试时，系统变量 $(OutDir) 的值是最先确定的，而 $(TargetDir) 和 $(TargetPath) 的值是在链接器生成 exe 文件后才确定的。 “调试”栏目中的“命令 (Command) ”属性项，这个属性表示启动调试器时执行的 exe 文件“ 全路径名 + 文件名”，默认为链接器生成的 $(TargetPath) 目录， 当然你也可以手动更改 “ 命令 ” 属性的值。 图 3 单击调试按钮 (VS 中的那个小三角形按钮 ) ， VS 会起动图中所示目录下的 exe 文件。一般来说“链接器”— “输出文件”与“调试”— “命令”中的文件位置、名称是相同，以表示链接器生成的文件和调试时使用的文件一样。一言以蔽之，① “调试”— “命令” 、② TargetPath 、③ 输出文件，④ 输出目录 (OutDir) 默认情况下是处于同一个目录，并呈现出前一个紧密依赖于后一个的关系。 2.5 调试 — 工作目录 工作目录 (WorkingDirection ) 与执行目录 (Command) 可以不同， 它是程序工作运行过程中默认读取的目录， 调试时是将工作目录下的文件作为附加参数添加到执行目录的 exe 文件中去调试执行。 “调试”栏目中的“工作目录”项，默认属性值为 $(ProjectDir) ，即工程配置文件 MyProject.vcproj 所在目录，调试过程中它会随着 OpenFileDialog 、 SaveFileDialog 等对象所确定的目录而改变。对于静态链接的 lib 和 dll 库文件可以放入 exe 所在的执行目录，而动态加载的 dll 一般放在工作目录，比如插件就放在工作目录。此外，程序运行过程中生成一个 txt 文本文件或读取一些配置文件，如果在创建或读取过程中未指定绝对路径，只指定其文件名，那么默认的路径就是工作目录。 VS 中工作目录是用于调试过程，只有在调试时， VS 才会把项目配置属性中的工作目录设置为执行进程的工作目录，然后再启动对应的 exe 程序。如果用户选择直接双击一个 exe 程度启动新进程， VS 会自动把 exe 文件所在的目录设置为新进程的工作目录。 因此，在软件部署发布的时候，需把工作目录内的文件拷贝到 exe 所在的执行目录内，否则就会运行出错。 2. 6 链接器 — 输入 — 附加依赖项 “链接器”栏目下，“输入”选项下，“附加依赖项”属性。此项是设置程序链接时使用的静态库的名称。相当于链接已经编译好了的“代码”。由此我们可以简单的认为这些库就相当于我们自己写的源文件，只不过这些库是编译好了的源文件而已。 图 4 三、案例操作演示 3.1 前期准备工作 为了增强读者对前面内容的理解，此部分将通过一个实际的案例对其进行演示，假设我们期望的目录结构如下图所示。解决方案的名称为 GMA ，包含一个动态链接库项目 ChocolateMilk( 生成 dll) 和一个应用程序项目 PureMilk( 生成 exe) ，需要使用一个第三方库 log4cxx(Apachelog4j 的 C++ 移植版本，用于日志输出 ) 。 log4cxx 是以动态库的方式编译的，所以我们需要它的①导入库 (log4cxxd.lib) ，②头文件和③动态链接库 (log4cxx.dll) ，分别位于 Lib 、 Include 和 Bin 中。 图 5 1) GMA 是解决方案目录 2) PureMilk 和 ChocolateMilk 是项目目录 3) Lib 目录用于存放导入库或者静态库 ( 包括第三方库和用户项目生成库 ) 4) Include 用于存放 第三方库 的头文件 5) Bin 目录存放所有动态链接库和执行档，包括自己的产出和第三方库，分 Release 和 Debug 两个版本。另外，程序运行过程中需要外部的数据文件和启动时需要的配置文件等等都可放于该目录 6) Temp 用于存放临时生成文件，其中 Compile 存放编译器编译时生成的 obj 文件， Link 存放链接器的输出文件。 7) PureMilk 和 ChocoliteMilk 两个项目的头文件和源文件位置不要动，仍然在各自的项目文件夹内。 上面目录结构清晰，一目了然，当我们的程序需要制作安装包时我们只需将 “Bin/Release” 目录下的所有文件打包。而在发布和转移源码时我们可以打包除了 Temp 目录以外 “GMA” 目录下的所有文件和目录。如果不需要执行档，还可不包括 Bin 文件。 然而， VC 2008( VS 2008) 并不会自动为用户准备好上面的所有的配置，其中一些工作的需要用户修改项目的缺省设置来完成。 1) 使用 “/GMA/Temp/Compile/” 作为项目编译时使用的中间目录 2) 使用 “/GMA/Temp/Link/” 作为项目链接的输出目录 3) 当项目是应用程序时，在构建结束后拷贝执行文件到 “/GMA/Bin/Release/” 或 “/GMA/Bin/Debug/” ，当项目是动态链接库时，除了拷贝 dll 到 Bin ，还拷贝导入库到 “/GMA/Lib/” 4) 当项目是应用程序时，调试时运行 “/GMA/Bin/Debug/” 或 “/GMA/Bin/Release/” 下面的执行文件，并以 “/GMA/Bin/Debug/” 或 “/GMA/Bin/Release/” 为工作目录 3.2 开始两个项目配置属性设置 3.2.1 动态链接库项目 ChocolateMilk 配置属性 1) 使用 “/GMA/Temp/Compile/” 作为项目编译时使用的中间目录 2) 使用 “/GMA/Temp/Link/” 作为项目链接的输出目录 图 6 注意高亮的部分，首先将配置改成 All Configuration( 全部配置 ) ，这样可以让我们同时修改 Debug 和 Release 的部分； Output Directory ( 输出目录，链接器 ) 栏位填入： $(SolutionDir)\Temp\Link\$(ProjectName)\$(ConfigurationName) Intermediate Directory ( 中间目录，编译器 ) 栏位填入： $(SolutionDir)\Temp\Compile\$(ProjectName)\$(ConfigurationName) 3) 默认设置的 dll 和 lib 生成文件为输出目录中，因此构建结束后拷贝动态链接库到 “/GMA/Bin/Release/” 或 “/GMA/Bin/Debug/” ，拷贝导入库到 “/GMA/Lib/” 。 我们通常都会在 Debug 版本的输出库后面加上字母 “d” 以表示这是 Debug 版本，在 Debug 配置下，修改 Import Library 属性为 $(TargetDir)$(TargetName)d.lib ： 图 7 为了实现构建结束后动态链接库和导入库的拷贝， VC 可以让我们设置构建前后执行的脚本程序，需要我们写构建后执行的脚本： 图 8 由于 VC 中缺少表示导入库的系统变量值，所以在 Command Line 设置时需要分别设置 Debug 配置下： copy “$(TargetPath)” “$(SolutionDir)\Bin\$(ConfigurationName)\” ； copy “$(TargetDir)$(TargetName)d.lib” “$(SolutionDir)\Lib\” ； Release 配置下： copy “$(TargetPath)” “$(SolutionDir)\Bin\$(ConfigurationName)\” ； copy “$(TargetDir)$(TargetName).lib” “$(SolutionDir)\Lib\” ； 3.2.2 应用程序项目 PureMilk 配置属性 1) 使用 “/GMA/Temp/Compile/” 作为项目编译时使用的中间目录 2) 使用 “/GMA/Temp/Link/” 作为项目链接的输出目录 将配置改成 All Configuration ，这样可以让我们同时修改 Debug 和 Release 的部分； OutputDirectory( 输出目录，链接器 ) 栏位填入： $(SolutionDir)\Temp\Link\$(ProjectName)\$(ConfigurationName) IntermediateDirectory( 中间目录，编译器 ) 栏位填入： $(SolutionDir)\Temp\Compile\$(ProjectName)\$(ConfigurationName) 3) 构建结束后拷贝执行文件到 “/GMA/Bin/Release/” 或 “/GMA/Bin/Debug/” 在 Command Line 中填入， All 配置下： copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName); 4) 调试时运行 “/GMA/Bin/Debug/” 或 “/GMA/Bin/Release/” 下面的执行文件，并以 “/GMA/Bin/Debug/” 或 “/GMA/Bin/Release/” 为工作目录 图 9 Command 栏填入： $(SolutionDir)\Bin\$(ConfigurationName)\$(TargetFileName) WorkingDirectory 栏填入： $(SolutionDir)\Bin\$(ConfigurationName)\

16415 次阅读|0 个评论

什么是定制软件开发？

jintuwl 2014-5-23 11:06

定制软件开发是指开发软件，迎合某公司或个人的具体需要和要求的过程，或是 行业网站建设 ，或是 企业网站建设 。它使企业能够创建一个软件，这是特别适合自己的流程和环境。 公司总是会想出有创意的想法，会让他们在特定的行业领先。随着我们的世界对技术要求的提高，定制软件开发被视为关键在促进业务,推动他们高于其竞争对手和给他们一个额外的优势。 使用自定义的软件开发企业为了生产高效率和高质量的输出，在他们的领域的业务，销售，库存管理，信息的存储和分配，数据采集等增强实力。选择定制的软件开发资讯公司是至关重要的。除了提供必要的软件，好的公司应还应该能提供担保以及对其所开发的产品和 网站开发平台 提供全面的技术支持。他们应该确保他们的产品是可靠的,质量是良好的,以满足用户的需求。一个软件开发公司也有乏味的任务，比如一次又一次的测试和修改他们的产品,以确保他们完美适应的软件交付给客户。不断的沟通也很重要，使客户软件开发资讯公司和用户公司之间的关系从头脑风暴阶段到发展阶段。 在一个软件开发公司，对比只生产供大众消费的商业软件的公司;定制软件开发公司需要施加更多的努力。更多的时间和精力投入只是为一个特定的用户或公司输出更好的软件。商业软件制造商只涉及创造单个周期产品和其他的工作去生产、营销、维护和开发,定制软件制造商创建的产品涉及多个周期的都不同于另一个。一个定制的软件比现成的商业软件更贵。它作为一个更加复杂的市场营销和工程阶段，还需要一个过程更艰难的研究和开发。 一个优化充分，完全定制的软件，将使公司能够产生更好的结果和更高效的服务。最后，定制软件开发带来的好处远远超过其成本，这就是为什么它是一个伟大的投资促进业务。 http://www.jintuwl.com/

个人分类: 网络开发|12 次阅读|0 个评论

试谈CAE软件开发和知识产权保护

lzj6189 2014-2-12 20:21

中国力学学会计算力学专业委员会、《计算机辅助工程》杂志社定于2013年7月举办计算机辅助工程应用与理论研讨会2013(CAETS 2013)。约稿，写了些，约7000字，依然觉得不够完整。虽不够专业，但情真意切；虽不够专业，但其心可鉴。见谅！ http://lzj6189.blog.163.com/blog/static/6243782720135891392/ 知识产权是为激励人们发明创新而设立的一种法律制度安排，寻求专利保护无疑是知识经济时代一种最为有效的法律保护形式。长期以来，计算机软件的保护都主要是以保护计算机软件“著作权”人权益的方式来调整计算机软件在开发、传播和使用中发生的利益关系，而2006年以后所颁布的，目前所执行的2010年第四次修改后《专利审查指南》规定，只要符合相关条件，也可以申请专利保护，由此而来，使软件保护更加充分而且有效。 通常软件的知识产权保护就是指计算机软件的版权保护。自2013年3月1日起施行的《国务院关于修改〈计算机软件保护条例〉的决定》，就是以“为了保护计算机软件著作权人的权益，调整计算机软件在开发、传播和使用中发生的利益关系，鼓励计算机软件的开发与应用，促进软件产业和国民经济信息化的发展”所制定的条例 根据计算机软件保护条例规定，“保护计算机软件著作权人的权益”是以保护计算机软件的表现形式为方式，属于著作权法的一种。 著作权法只保护计算机软件的表现方式，而体现计算机软件价值的是所提供的解决问题的方案和技巧，其知识成果是软件的关键所在。在这个阶段，软件的知识产权通常指的就是计算机软件的版权。因此，开发商为保护自己的利益，通常采用软件加密和硬件加密的方式，目的是不被盗版。 目前执行的是2010年的第四次修改后《专利审查指南》的规定，其规定与2006年的《审查指南》相比基本没有变化。然而，与2006年前的版本相比，关于计算机软件的专利保护形式，对于以前申请专利的技术内容必须包含对计算机硬件的要求，有所改变。相比较２００６年前的软件著作权法保护，计算机软件的申请专利保护，其保护形式和力度更加充分和有利。 专利保护针对的是计算机软件的内容和思想，表现形式是解决问题的方案和功能。显然，功能和方案具有较大的范围，功能确定了，通过其它途径的实现都可能落在这个范围内为被认为是侵；受技术方案实施的限制，他人难以回避和逾越。因此正确理解和运用《专利审查指南》的规定，对于软件开发商和知识成果拥有者，是保护自身利益的有效工具和战略。 数值仿真技术是建立在数学模型、算法、公式和设计等基础上的一系列对现实世界的模拟过程。模拟的复杂性有赖于对抽象世界的创造性认识，并得到验证；其实现的过程有赖于硬件所能提供的计算能力和实验条件。基于计算力学理论的CAE软件，其核心思想是数值仿真研究与求解技术。 正是这种创造性的研究工作，使得CAE软件系统的技术特性随时保持着与国家先进装备制造业同等的发展水平和战略要求。在现行考核制度下，成功的标准取决于已经发表了多少论文，有许多部门，为了保护自身研究成果，对考核制度进行“变通”，以内部认可的方式予以承认其数量和水平，目的很明确，保护；在许多工程项目攻关时，为提高科技含量和完善技术问题，有许多部门，学习和寻找已经发表的科研成果予以参考和借鉴，不失为一条捷径。知识产权制度既为产权界定并提供激励机制，同时也是进行资源配置并提供市场交易和规范的法律机制。创造者和应用者之间，是一种对创造性知识成果的资源与利益进行配置的市场行为，知识产权在合作和竞争之间，是体现社会经济、科技实力的重要指标，是提供互助互补、共赢共荣的规范机制。 作为一名科技工作者，尝试用并不熟练的知识产权知识，探讨与自主软件产业发展的关系，是想抛砖引玉，引起重视，务必尊重知识创新和守护应有权益。

3474 次阅读|0 个评论

软件开发启示录——迟到的领悟

yangtaolyt 2013-11-8 16:36

软件开发启示录——迟到的领悟 作者: John Sonmez 来源: IDF实验室博客 发布时间: 2013-10-20 15:47 阅读: 9704 次 推荐: 70 原文链接 　　 英文原文： 4 Things I Wish I Would Have Known When I Started My Software Development Career 　　我的软件开发生涯开始于15年前。 　　但是直到最近的5年，我才真正开始看到自己在软件开发领域的巨大进步。 　　这里有一些感悟是我希望能够在我进入软件开发领域时所知道的事情，如果我早一些领悟到，相信会比现在更加成功，也更节省一些时间。 　　软件开发工作没有“正确方法” 　　在软件开发生涯的早期，我曾经浪费了大量的时间在学习和争辩，错误的相信有一条“绝对正确的方法”能够应付软件开发的很多方面。 　　结果证明我曾经认为关于软件开发的每一件正确的事情到最后都是错误的。 　　但是更重要的是，我发现很少有事情是黑白分明的。在写代码和开发软件时所做的几乎每一个决定都取决于当时所处的环境。 　　我曾经讨论过关于技术的宗教式信仰是如何对软件开发者不利的，但这个话题已超出技术范畴。 　　没有万能的最佳实践方式，这句话很对。甚至像“是否应该进行单元测试”、“敏捷开发和瀑布模型哪个最好”这种高热度的话题都不会有一个直截了当的简单答案。 　　在我的职业生涯中，我已经浪费了大量时间在这种“正确方法”上以至于最终一无所获，而不是探寻可以让我走更远的“实用主义”道路。 　　一页一页看书不是最佳的学习方式 　　当我第一次想提升自己的编程水平和各种技术水平时，我花了非常多的时间一页一页地读具体的技术类的书。 　　读书并没有错，但是要有选择那些重要的书和重要的章节读。 　　比如，我记得我曾经读过一本非常厚的关于Visual C++的书（我非常确定是《Beginning Visual C++ 2012》的早期版本）。总之，这本书是一本包含了海量知识的好书，但是一页一页读并不是学习Visual C++的最佳途径。 　　早知道我就应该像过流水账一般地粗略地看下这本书的所有章节，以了解Visual C++包括哪些知识点，然后再考虑哪些部分是最重要的，是应该首先读的。 　　如果我坐下来实际练习下书中的基础练习题而不是仅仅看过或跳过这些例子的话，会有更多的收获。除非你实际用你的所学解决了实际的问题，否则算不上你学会了这门技术。 　　深入学习特别技术是浪费时间 　　我不仅仅浪费时间在一页一页的读书，还经常选择了那些错误的书读。 　　曾经的我花费了大量的时间读诸如ASP.NET或Hibernate等特别技术的书，而不是读像《代码大全》、《代码整洁之道》、《敏捷软件开发：原则、模式与实践（C#版）》（顺便说一句，如果你还没有读过这些书，我推荐你读一读）。 　　比起知道你所用的技术的重要性，成为某一特别领域的专家是不重要的。知道某一个具体API调用一点好处都没有，当你需要它的时候只要查询下就好了。 　　我曾经花费大量时间深入学习的许多技术中，到最后要不这技术逐渐没落，要不就是太过技术以至于我自己放弃了它。这些特别技术中的绝大多数最终都证明是在浪费时间。 　　只要是我正在使用，无论什么语言，成为这种编程语言方面的专家都是很重要的，因为在一门特殊语言方面的专业知识能够让你活跃在软件开发领域许多年。当然，我仍然在花时间深入学习C++、C#和JAVA，但是，对于现在的我来说，可能多花一点时间在C++的各种纷繁难懂之处并没有什么好处。 　　技术社区在软件生涯中极其重要 　　在我早年的职业生涯中，我犯过的一个错误就是没有投入到技术社区中求助或帮助他人。 　　我总是乐于帮助我的同事，并和我所接触的各类职业打交道，但从来超出我所在公司的人员和岗位范围。 　　曾经我花了大量时间将自己投入在所在公司的职业生涯中，而没有在软件开发社区中投入一点时间，这点非常的不划算。 　　曾经我花时间致力于内部技术建设的分享或实践，原本也可以在技术社区中做同样的分享和交流，也同样会给我带来工作上的认可。 　　我也错误的认为我没有什么有价值的事情贡献给技术社区。 　　现在的我会和很多软件开发的新手们聊天，有时候我想相比我们他们一定花了很多精力贡献在技术社区，因为和其他新手相比较，他们看起来没有懂的更多，也没那么抓狂。 　　如果时光能够倒流，我确信年轻时候的自己一定会投入很多时间在技术会议和用户群组上，我会尽早地开始写自己的博客并创建自己的项目和资源与其他人分享，而不是呆呆地读书。 　　永远有编外项目在做 　　影响我职业生涯最大的选择可能就是杜绝看电视、《无尽的任务》和《魔兽世界》游戏了，取而代之的是将这些时间用在我的编外项目上。 　　在过去的生活中我已经浪费了很多时间在做娱乐活动，而不是那些能够充实我生活的事情。 　　在大约3-4年前，我已经基本和看电视这种活动决绝了，现在的我甚至都很少看电影。看电视和看绝大多数电影都是一种时间浪费，浪费那些原本可以做一些有用之事的时间。多数的电视游戏也是如此，但至少玩电视游戏收获的也不仅仅只是无用信息。 　　我非常喜欢玩电视游戏，而且恐怕也不会有停手的那一天，但是我着实希望我能够把花费在玩游戏、看电视的时间投入在自有的项目上。 　　不幸的是，我真正开始自己的第一个项目却是在大约3年以前，那时的我开始着手创建一个Android应用程序。 　　当你为别人工作时，能够花时间在自己的项目上非常重要，否则就是在牺牲自己的精力为别人建造帝国。 　　在过去的几年间，我不仅从编外项目中学习到了不少东西，而且也从其中得到了巨大的利益。事实上，其中的一个编外计划：创建Pluralsight课程，是我现在正全职在在做的事情。 　　将所学揉合起来 　　以上所说是少数我后悔没有在自己职业生涯开始时知道的感悟，但从一开始我仍然做了很多正确的事情。 　　实际上我在一个绝密项目中正将这些信息结合起来帮助开发者开始他们的职业生涯并让他们学会推销自己。

1 次阅读|0 个评论

我希望在软件开发生涯初期就知道的4 件事

yangtaolyt 2013-10-22 20:59

我希望在软件开发生涯初期就知道的4 件事 2013-10-19 08:20 阅读(45) 原文出处： John Sonmez 译文出处： IDF实验室 我的软件开发生涯开始于15年前。 但是直到最近的5年，我才真正开始看到自己在软件开发领域的巨大进步。 这里有一些感悟是我希望能够在我进入软件开发领域时所知道的事情，如果我早一些领悟到，相信会比现在更加成功，也更节省一些时间。 软件开发工作没有“正确方法” 在软件开发生涯的早期，我曾经浪费了大量的时间在学习和争辩，错误的相信有一条“绝对正确的方法”能够应付软件开发的很多方面。 结果证明我曾经认为关于软件开发的每一件正确的事情到最后都是错误的。 但是更重要的是，我发现很少有事情是黑白分明的。在写代码和开发软件时所做的几乎每一个决定都取决于当时所处的环境。 我曾经讨论过关于技术的宗教式信仰是如何对软件开发者不利的，但这个话题已超出技术范畴。 没有万能的最佳实践方式，这句话很对。甚至像“是否应该进行单元测试”、“敏捷开发和瀑布模型哪个最好”这种高热度的话题都不会有一个直截了当的简单答案。 在我的职业生涯中，我已经浪费了大量时间在这种“正确方法”上以至于最终一无所获，而不是探寻可以让我走更远的“实用主义”道路。 一页一页看书不是最佳的学习方式 当我第一次想提升自己的编程水平和各种技术水平时，我花了非常多的时间一页一页地读具体的技术类的书。 读书并没有错，但是要有选择那些重要的书和重要的章节读。 比如，我记得我曾经读过一本非常厚的关于Visual C++的书（我非常确定是《Beginning Visual C++ 2012》的早期版本），总之，这本书是一本包含了海量知识的好书，但是一页一页读并不是学习Visual C++的最佳途径。 早知道我就应该像过流水账一般地粗略地看下这本书的所有章节，以了解Visual C++包括哪些知识点，然后再考虑哪些部分是最重要的，是应该首先读的。 如果我坐下来实际练习下书中的基础练习题而不是仅仅看过或跳过这些例子的话，会有更多的收获。除非你实际用你的所学解决了实际的问题，否则算不上你学会了这门技术。 深入学习特别技术是浪费时间 我不仅仅浪费时间在一页一页的读书，还经常选择了那些错误的书读。 曾经的我花费了大量的时间读诸如ASP.NET或Hibernate等特别技术的书，而不是读像《代码大全》、《代码整洁之道》、《敏捷软件开发：原则、模式与实践（C#版）》（顺便说一句，如果你还没有读过这些书，我推荐你读一读）。 比起知道你所用的技术的重要性，成为某一特别领域的专家是不重要的。知道某一个具体API调用一点好处都没有，当你需要它的时候只要查询下就好了。 我曾经花费大量时间深入学习的许多技术中，到最后要不这技术逐渐没落，要不就是太过技术以至于我自己放弃了它。这些特别技术中的绝大多数最终都证明是在浪费时间。 只要是我正在使用，无论什么语言，成为这种编程语言方面的专家都是很重要的，因为在一门特殊语言方面的专业知识能够让你活跃在软件开发领域许多年。 当然，我仍然在花时间深入学习C++、C#和JAVA，但是，对于现在的我来说，可能多花一点时间在C++的各种纷繁难懂之处并没有什么好处。 技术社区在软件生涯中及其重要 在我早年的职业生涯中，我犯过的一个错误就是没有投入到技术社区中求助或帮助他人。 我总是乐于帮助我的同事，并和我所接触的各类职业打交道，但从来超出我所在公司的人员和岗位范围。 曾经我花了大量时间将自己投入在所在公司的职业生涯中，而没有在软件开发社区中投入一点时间，这点非常的不划算。 曾经我花时间致力于内部技术建设的分享或实践原本也可以在技术社区中做同样的分享和交流，也同样会给我带来工作上的认可。 我也错误的认为我没有什么有价值的事情贡献给技术社区。 现在的我会和很多软件开发的新手们聊天，有时候我想相比我们他们一定花了很多精力贡献在技术社区，因为和其他新手相比较，他们看起来没有懂的更多，也没那么抓狂。 如果时光能够倒流，我确信年轻时候的自己一定会投入很多时间在技术会议和用户群组上，我会尽早地开始写自己的博客并创建自己的项目和资源与其他人分享，而不是呆呆地读书。 永远有编外项目在做 影响我职业生涯最大的选择可能就是杜绝看电视、《无尽的任务》和《魔兽世界》游戏了，取而代之的是将这些时间用在我的编外项目上。 在过去的生活中我已经浪费了很多时间在做娱乐活动，而不是那些能够充实我生活的事情。 在大约3-4年前，我已经基本和看电视这种活动决绝了，现在的我甚至都很少看电影。看电视和看绝大多数电影都是一种时间浪费，浪费那些原本可以做一些有用之事的时间。多数的电视游戏也是如此，但至少玩电视游戏收获的也不仅仅只是无用信息。 我非常喜欢玩电视游戏，而且恐怕也不会有停手的那一天，但是我着实希望我能够把花费在玩游戏、看电视的时间投入在自有的项目上。 不幸的是，我真正开始自己的第一个项目却是在大约3年以前，那时的我开始着手创建一个Android应用程序。 当你为别人工作时，能够花时间在自己的项目上非常重要，否则就是在牺牲自己的精力为别人建造帝国。 在过去的几年间，我不仅从编外项目中学习到了不少东西，而且也从其中得到了巨大的利益。事实上，其中的一个编外计划：创建Pluralsight课程，是我现在正全职在在做的事情。 将所学揉合起来 以上所说是少数我后悔没有在自己职业生涯开始时不知道的感悟，但从一开始我仍然做了很多正确的事情。 实际上我在一个绝密项目中正将这些信息结合起来帮助开发者开始他们的职业生涯并让他们学会推销自己。 如果你想成为这个项目正式启动后的第一个参与者，在这里注册，到时我会通知你。 你有什么感悟？ 当你开始自己的软件开发生涯时你希望有哪些经验与大家分享呢？请留言让我知道

2 次阅读|0 个评论

CBSD 面向构件的软件开发

jiangdm 2013-7-10 07:57

Contents 1 2 一种具有高度可扩展性和灵活性的软件模型研究 3 Software Component Engineering Course Sequence Textbooks Ohio University http://www.cse.ohio-state.edu/sce/book/ 一种具有高度可扩展性和灵活性的软件模型研究 陈传波, 魏书光 计算机工程与科学 2004 摘要 针对传统软件可扩展性和灵活性低的问题, 本文提出了一个软件模型。通过把软 件分割为不同的部分, 并协调各部分的运行来实现软件的可扩展性和灵活性。另外, 本文还对的 概念定义及设计原理进行了讨论。 图1是的原理图 一种具有高度可扩展性和灵活性的软件模型研究.pdf I comment: no content, only title. *** ##面向构件与方面的MDA软件开发新模型初探 袁梅冷 《计算机工程与设计》 2007年11期 摘要： 以面向对象为基础的基于构件(CBSD)的软件开发方法、面向方面(AOSD)方法以及基于模型递进驱动(MDA)的软件设计与开发方法各具优点,分别从不同角度很好地解决了软件开发中遇到的不同问题,却各有不足,在对CBSD、AOSP以及MDA等方法的研究基础上,提出了一种新的面向构件与方面的MDA软件开发模型,该方法通过计算模型、构件与方面模型、系统实现模型这3种逐步递进的模型采进行复杂系统的软件设计与开发。给出的应用实例表明该开发模型能有效降低复杂系统的开发难度,提高开发效率以及系统的复用性。 面向构件与方面的MDA软件开发新模型初探.pdf I comment: a big title, a little contents

个人分类: Software|2 次阅读|0 个评论

new

jiangdm 2013-5-31 16:39

ew

个人分类: CHI|3 次阅读|0 个评论

[转载]德国癌症研究中心医学信息学团队希望加强在MITK软件开发上的合作

zhouzhuhuang 2013-4-17 21:30

德国癌症研究中心DKFZ，是德国亥姆霍兹国家研究中心联合会18个成员单位之一： http://www.dkfz.de/en/dkfz/index.html 。 DKFZ共有员工2500人，其中1000人为科学家。 主要从事癌症机理的研究，包括查找癌症风险因子、癌症预防以及治疗手段、手术控制等等。DKFZ也在与同为亥姆霍兹联合会的达姆斯达特重粒子加速器中心GSI合作，联合开展重粒子治疗肿瘤的设备以及手段和疗效研究。 德国癌症研究中心的医学图像与生物信息学团队，有五十人之多，是世界上从事医学影像3D再建、手术导航领域的顶尖的研究团队之一。除政府渠道的课题之外，也收到包括西门子、德国电信等机构的企业经费。 今年8月底及9月初，团队负责人P. Meinzer教授将携软件开发平台的负责人Nolden先生来京访问交流，他们除有意对几家医院介绍肿瘤病理容积变化监控、肝脏手术导航等软件外，也希望跟中方从事MITK开源软件开发团队建立学术交流与合作关系：www.mitk.org. 希望中方有意交流信息开展合作、同时也有相当实力的MITK开源软件开发团队跟亥姆霍兹联合会北京代表处进行联系，以确认学术交流计划与日程。 亥姆霍兹联合会北京代表处地址： 北京朝阳区东三环北路8号、亮马河大厦2-1723 010-659907865； info@helmholtz.cn http://blog.sciencenet.cn/blog-320892-591715.html

2098 次阅读|0 个评论

IBM招聘 软件开发与性能测试 实习生

lixiangdong 2013-3-9 20:00

Software Developer and Tester for Performance Intern, 12/16 Months Markham May The following STUDENT position is a part of IBM Canada's EPIC (Employment Pathways to Interns Co-ops) Student Program. This position is only open to students registered in a Canadian University or College program, who have completed a minimum of 2 years of their degree or diploma program , and who must be returning to full-time study upon the completion of the temporary IBM work term. This Student Position resides in Toronto and is only a 12/16 MONTHS work term Title: Software Developer and Tester for Performance Overview: We are looking for highly motivated individuals who want to understand how systems work together and be the expert in database performance engineering. The Information Management (IM) Performance and Solutions team is an elite world wide team with skills that span from enhancing the kernel of DB2/solidDB data server , configuring and tuning of complex DB2 , solidDB and Master Data Management (MDM) systems, prototyping and implementing innovative solutions , and providing world-wide consultation on best practices and architecture for performance. The team works with millions of dollars of hardware from various vendors (e.g., IBM, Intel, AMD, HP, and Sun) at the lab and there are opportunities to do hands-on work with them. Main Responsibilities include: You will be involved and gradually build up expertise in one or more of the following areas: Work with IBM and non-IBM hardware and software vendors to exploit new features and achieve higher level of performance with the DB2, MDM, and solidDB products. Improve performance of these products with prototyping, performance studies, and regression testing. --数据库性能优化 Develop innovative solutions that put together hardware and software products to improve competitiveness and ease of use. 系统方案设计与优化 Produce world record performance benchmark results with large SMP and MPP systems to demonstrate the superior performance of DB2, MDM and solidDB. Examples of benchmarks include TPC-C, TPC-E for Online Transaction Processing (OLTP), TPC-H, SPECjAppServer for J2EE, TPoX for XML, and SAP. 产品性能标准 Develop tools to improve problem determination and performance data analysis. 错误定位与数据分析 Investigate and exploit technology involving computer architecture, storage sub-systems, OLTP systems, data warehouse systems, query optimization, virtualization, and XML data retrieval 体系结构、存储子系统、交易系统、数据仓库系统、查询优化、可视化、XML数据检索等新技术开发与应用 Support proofs-of-concept in high performance environments (OLTP, data warehousing, etc) with high profile customers and projects. 高性能环境技术POC As the last line of defense for critical situations in IBM involving DB2, MDM and solidDB performance issues with customers, bringing chaos into order in a complex environment involving many products. 灾难恢复 Share our insights with articles and presentation to forums and conferences. 发表论文参加国际会议 Qualification (industry and/or classroom experience): Excellent oral and written communication, teamwork, and debugging skills. Very quick learner of technology, be able to multi-task, and see clarify in complex situation. C, Java, scripting language (e.g., Perl, shell script, etc), concept and usage of DBMS systems. Experience with UNIX, Linux, or Windows. Experience with any of the following would be an asset but not required: Performance testing methodology and tools. Administering, monitoring, and tuning skills for DB2 (or other DBMS), WebSphere (or other application server), or MDM products such as InfoSphere MDM. XML XPath, XML Schema, XQuery Computer architecture, storage sub-system, OLTP system, data warehouse systems, query optimization, and virtualization More importantly, someone who loves to work with systems and wants to understand the internals. Contact: Michael Kwok (mkwok@ca.ibm.com) WHAT IBM OFFERS YOU: 1. Work directly on product and services that affect our clients, while having access to cutting edge software technology. 2. Work is challenging and rewarding. 3. Access to obtain IBM Product Certificate during work term. 4. A casual dress code and flexible work hours Required High School Diploma/GED English: Fluent IBM is committed to creating a diverse environment and is proud to be an equal opportunity employer. All qualified applicants will receive consideration for employment without regard to race, color, religion, gender, gender identity or expression, sexual orientation, national origin, genetics, disability, age, or veteran status.

个人分类: 海外职位|2457 次阅读|0 个评论

IBM招聘软件开发（测试）人员

lixiangdong 2013-3-9 19:34

Software Developer Reporting to the Manager of Systems Integration, the successful candidate will be involved with test automation , regression testing , analyzing test results , reporting and tracking defects , verifying fixes and follow-up work to resolve issues related to the Algorithmics software developed in high level languages (Java, C++). The role requires in-depth knowledge of software testing methodologies with the objective to establish and maintain high quality test procedures and methods to be used in software development and testing. The role includes the development of test plans and test cases from feature descriptions, understanding of software release process and focusing on policies and procedures necessary to ensure high quality of released solutions. The candidate will be required to interact directly with internal and (at times with) external clients on technical support and configuration issues and must be comfortable in a fast-paced environment. Participate in software development and implementation initiatives on a range of Algorithmics Solutions; undertake setup and configuration of the Algorithmics and third party products (database, middleware, reporting solutions) troubleshooting and testing (functional, performance, usability, etc) Communicate with internal stakeholders to analyze new product features and develop corresponding test cases and baselines for the wide range for the Rick Management Solutions, such as Counterparty Credit Risk, Balance Sheet Risk Management, Regulatory Market and Credit Risk Reporting, CVA and other Develop test plans, and via a test harness, implement and execute the test cases to test new and existing software features according to the functional/technical software specifications Analyze test harness results, investigate problems and communicate findings to stakeholders Provide technical support to various groups of stakeholders within the company and, occasionally, to external customers Expand regression test harness for new daily operations and offerings (CCR and RTCE) Improve the reliability of the test automation framework Investigate and troubleshoot system operations and performance issues Establish and oversee the quality tests and trends, qualify Company releases and perform corrective and preventive actions as necessary Education The position calls for a university degree or graduate degree in a quantitative discipline such as Computer Science, Mathematics or Engineering Special Skills Experience with data manipulation and transformation using Perl and/or Unix shell scripting Comfortable working knowledge of UNIX (e.g. Solaris, Linux, AIX) and MS Windows Familiarity with Object Oriented Programming concepts and languages (e.g. Java, C++, etc.) Knowledge of database concepts and programming (e.g. SQL, sizing, installation, performance) Familiarity with database products (e.g. Oracle, DB2, Sybase, MS SQL Server) Systems interfacing or data migration between systems with mapping tools or solutions Proven ability to adapt to, learn and explore new technologies. Proven ability to work with complex software products with minimal supervision. Knowledge of software engineering design principles, software verification, automated testing Knowledge of software testing methodologies (Agile, Spiral, Waterfall) and methods (Integration, Regression, Performance, Stress testing, etc) Knowledge of policies and procedures necessary to ensure high quality software releases Strong analysis, demonstrative investigation and problem solving skills Strong verbal and written communication skills. Desirable Requirements Experience in banking or financial services sectors would be beneficial Current experience in Business Analysis and QA support of the production Enterprise Risk Management Systems Required Bachelor's Degree At least 5 years experience in Shell Scripting At least 5 years experience in data manipulation, transformation and clenasing using scripting languages At least 5 years experience in Object Oriented Languages (C++, Java) English: Fluent

个人分类: 海外职位|2532 次阅读|0 个评论

软件开发的误区——大家一起出恭

ws0110 2013-2-12 20:13

一直觉得软件开发中有三个最大的误区，今天有幸在我们中心的论坛中都遇到了，因此觉得有话要说（此文原发于2004年8月7日）： 1、让员工写日志。这是管理人员最偷懒也最无效的了解员工动态心态的做法，和监听器、摄像头等效，明显的一套安全局的特务做法，从此员工花在日志上的心机和时间比花在项目上的远甚； 2、让员工加班。不去找真正的症结所在，就像大海中的一条船，破了一个洞，招呼员工拼命地往外舀水，最终只是延缓了下沉的速度。 3、让员工定期参加会议。我只知道人每天一早起来喝杯水然后出恭是个好习惯，但我真不知道让一群人定期的一起喝水一起出恭有什么好处，然后别人喝水/出恭的时候，你必须在旁边洗耳恭听/睁大眼睛参观。其实，只有某个人便秘/或拉肚子/长时间霸占一个马桶/影响上下游出恭/的时候，大家才有必要讨论一下大便正常的秘诀呀，而这样的会干吗要定期开呢。 一个软件开发成功的秘诀不在于你是否找到了最优秀的人才，给他们配备最尖端的工具，然后给他们上最足的发条；知道皇马吗，齐/罗/菲/贝/卡/劳，都数不出来有多少个巨星了，整个一足球好莱坞，结果怎么样，赛季末五连败，还不就是赵丽蓉说的一盘萝卜炒大白菜。 一个软件公司成功的秘诀不在于他是否已经制定了一系列的制度，而是这些制度是否有效，中国人一日三餐，几千年也没怎么变，人大为什么不给它立个法？如果沟通已经成为软件人很自觉地一种生活方式，干嘛还要监听器/要定期出恭/要亡羊补牢呢？ (以下原发于2004年8月11日) 一个项目要成功，领导不通过日志也应该了解组长的工作、项目的进展，组长不通过日志也应该了解项目组成员的工作。而高层领导如果知道所有项目组都在朝着预定的目标前进，他干嘛要通过日志来了解每个成员每天的工作呢？还不如把时间省下来和大家吃地摊，打打球，玩玩牌呢？ 换句话说，毛泽东只要和林彪沟通，林彪只要和兵团司令沟通，兵团司令只要和师长、团长沟通...，如此这般，如果辽沈战役大获全胜的话，毛泽东难道有必要每周召开排以上干部会议，让每个排长甚至士兵挨个汇报一下（或者交上大家的日记）——这次辽沈战役你们排有没有逃兵、有没有开小差、有没有睡懒觉、有没有便秘、有没有浪费子弹、有没有优待俘虏吗？ 大家定期出恭只是为了自己一泄之快，并不是每次出恭都要向其它人汇报我今天有没有便秘，蹲了多长时间等等，所以我从来都反对汇报项目进展之类的例会。 你所说的每周开一二次的会议，我很同意开经验交流这样的会议，从别人那轻松拿来的主义，鲁迅建议为大家何乐不为？只是千万不要开成项目组挨个汇报自己一周所做工作的例会。 (以下原发于2004年8月14日) 问题的关键就在于，现在领导定义了一套自己所好的制度，然后就要求大家遵守，制度当然可以强制人在一定的时候做必须作的事情；但我们并不能说，制度可以让人在适当的时候做正确的事情。比如说清朝的制度要求大家留辫子，那我们现在干嘛不继续留着辫子呢？ 我希望表达的是，并不是有了制度，大家就必须遵守，如果制度有不好的地方，那我们就干脆“剪去它的辫子”，拿出阿Q的勇气，革他妈的命。在微软中，就有这样一位阿Q，他的名字叫史蒂夫.马魁尔，他剪掉了进度报告和进度会议的“辫子”，使微软的许多问题团队和项目起死回生。

个人分类: 随心随性|1949 次阅读|0 个评论

个人信息资源管理

liuchao666 2012-10-29 01:02

UriPackage.apk 个人信息资源管理的关键在于构建用户的私人语言，软件开发者的任务就是理解用户的私人语言，并协助用户整理用户的语言逻辑关系。 一般说来，以上过程可以包括三个部分: 第一，构建语言的基本要素，即元语言； 第二，利用元语言，构建语言， 第三，标识资源。 对于今天的计算机而言，以上三个部分是容易实现的。 难点在于，私人语言如何可以和其他人进行交流，即使用别人提供的服务或者给别人提供服务，进一步的，如何在提供私人语言服务的过程中，充分保护用户的隐私。 测试： UriPackage.apk

2783 次阅读|0 个评论

[转载]软件试用+免费试算+软件开发——元计算早期合作战略

serenashi 2012-9-27 10:59

早期合作是为帮助企业用户、科研机构解决急迫的项目研发需求，规避早期投入顾虑，是为建立战略互信和长久合作关系而推出的免费计算程序开发服务。 早期合作方案细则 1.元计算为有长久合作可能性，且有意愿参与早期合作的客户提供免费但有限度的试算和软件开发服务。有限度指投入有限和收获有限。 2.投入有限指元计算为客户无偿提供的早期投入不超过公司两个人月的成本；客户可以申请委托元计算进行程序开发、算例试算、紧急项目支持、软件模块开发等工作。 3.收获有限指在早期合作开发的成果中，用户仅免费获得需求的应用程序，但不包括程序源代码、相关技术说明文档等内容。用户可以无偿获得程序的使用权，但不获得所有权。 4.元计算欢迎意向客户在早期合作中也适当进行投入。根据客户投入的情况，元计算将相应的增加自身投入力度和扩展客户收获成果范围，保证用户获得满意的回报。 5.适用范围：企业、科研机构、高校以均可以向元计算公司提出申请。元计算将根据用户申请的先后顺序、客户长期合作可行性、客户算例的背景项目等情况进行综合排序和取舍。其中军工行业等国家支柱行业，对自主产权有强烈需求的客户优先。 6.知识产权：早期合作中元计算公司向用户提供的程序，用户拥有程序除商业用途之外的使用权。用户可基于开发内容发表论文、撰写相关报告，可以在元计算公司同意的情况下申请相关软件著作权、专利。元计算（天津）科技发展有限公司也可以提供有偿代理服务，代理服务内容包括基于程序的论文发表、著作权申请等。 7.早期合作方案有效期限：2012年8月1日至2013年7月31日 http://www.ectec.asia/info.asp?lb_id=770

个人分类: 学习|3181 次阅读|0 个评论

第六代编程语言及其软件开发环境的科学原理和底层技术

热度 1 geneculture 2012-7-17 12:12

第六代编程语言及其软件开发环境的科学原理和底层技术——三类双语协处理之形式化双重路径 美国加州大学（伯克利）塞尔研究中心双语信息处理课题组组长 邹晓辉 中国地质大学（北京）高等教育研究所 第六代编程语言及其软件开发环境的科学原理和底层技术.ppt 新增附图：

个人分类: 软件工程|2189 次阅读|4 个评论

中国计算机的软肋是软件开发

热度 4 Education 2012-3-26 09:43

其实不仅是加算机的系统软件，相关的应用软件中国也非常落后，比如追尾高铁的运控软件，飞机的控制软件。 在中国不仅大多数计算机类专业毕业生不想或搞不了开发，就算搞了几年以后也不想干了。 中国人到了美国就有不同的表现，主要流向软件开发行业，学数学物理化工等其他专业的大量转向软件。 同样的中国人，在中美会做出截然相反的选择， 原因在于官方事实上抹煞智力的差别，而是主要依靠权力，关系和简单的劳动时间分配报酬。 补充 江苏化学天才美国自杀 http://edu.sina.com.cn/a/2012-04-27/1041214840.shtml 这个人化学已经名冠全国了,还是转行学软件 PS: 中国还没有搞明白开发新技术的“正确方程式”，原因在于根据发表的论文数量而非工作质量获得报酬 http://tu.blog.china.com/201203/9503345.html 中国在开发超级计算机——它是现代科学的大脑，经济发展的引擎——方面出人意料的进展，过去两年间在这一领域长久以来无可争议的领导者美国国内引发了不安。中国在计算机领域的进展对其建造航天器和先进军用飞机以及其在遗传学方面不断增长的水平都至关重要。 据俄亥俄州哥伦布的研究机构巴特尔纪念学会的数据显示，中国在2010年超越日本，成为研发领域第二大投资者。尽管中国在研发支出方面仍然远远落后于美国，但它正日益壮大。 但如果对中国的超级计算机进行更仔细的观察就会发现，这个项目对美国技术优势的威胁远小于一般所认为的程度。中国研究人员称有关如何使用超级计算机的决定通常是由地方官员作出，他们对地方发展项目比对突破性新技术更感兴趣。 同时，中国的官员们还不了解如何启动接近美国或欧洲标准的软件开发项目。中国科学家们也缺少研究那些尚未获得政府支持的技术的资金和自由，这令他们远远落后于尖端技术。 - 结果就是中国的超级计算机项目并没有产生那种能够创造出新行业的突破。相反它只是被用于帮助中国在从医疗到汽车设计到航空等领域追赶美欧。这在经济上很重要，但这也提醒我们，中国仍然是一个发展中国家，其主要目标是缩小与更富裕国家之间的经济和技术差距。 俄勒冈大学中国科学政策专家理查德▪萨特迈耶说，中国还没有搞明白开发新技术的“正确方程式”，部分原因在于研究者是根据发表的论文数量而非工作质量和创新获得报酬的。 为“星云”超级计算机开发应用程序的深圳某研究机构副主管冯盛忠（音）说，为深圳超级计算机中心总成本出资三分之一的深圳“并不关心气候变化和天体物理学”——这两者都是传统超级计算机的研究项目——“他们关心的是地方问题”。 分析人士称，除了中国政府一贯的资助和支持之外，中国科学家还获益于在美国和欧洲的顶级计算机中心受训，以及来自国外的计算机芯片和其它部件。超级计算机方面的努力并未受到所谓中国窃取外国技术的指控的干扰。相反，中国科学家们称美国对一些高科技出口的限制要求他们更加努力。 中国仍然在很大程度上依赖于美国制造的微处理器一这是计算机的大脑——这令中国落后于技术前沿。北京方面已经开发出了一台使用自主设计微处理器的计算机，但它无法运行现有的商用软件。另一款正在开发的微处理器“龙芯”则将利用现有软件，并可能最终成为英特尔和其他处理器厂商的竞争对手。 市场研究公司国际数据公司超级计算机专家史蒂夫▪康韦说，在美国，市和州为地方超级计算机中心捐钱，但它们在决定超级计算机研究方向方面通常没有什么话语权。美国的超级计算机中心几乎总是以高级科研为中心，如设计为个人定制的药品之类。 进行前沿技术的研究是有风险的，但回报丰厚，并将中国这样的竞争对手远远甩开。俄勒冈大学的萨特迈耶说：“美国的危言耸听并不总是有道理。关键在于让美国的创新战略远远领先于竞争。” 中国最大的软肋之一就是软件开发 ，这是一个可能令其竞争力受到削弱的问题，因为计算机的用处取决于软件应用的质量。中国的研究者说，超级计算机资金中只有不到10%是用于开发这些应用程序的，他们抱怨政治领导人要求他们制造能够登上新闻头条的新机器，却不关注它们是否发挥了全部的能力。 在超级计算机支出6倍于中国的美国，软件预算相当于硬件支出的约30%，而计算机专家们说即使这一水平也还不够。 补充 在美国的2012年职业排名，最优质的职业是软件工程师。 http://www.bwchinese.com/article/1027561.html ps 赴美留学生目前就业形势最好的是计算机专业 http://edu.sina.com.cn/a/2013-11-15/0808236113.shtml 美国法律规定，公民在招聘中有优先权，留学生必须证明自己比美国人更优秀才有可能被聘用。虽然最终多数人都能找到工作，但是相当一部分人学非所用，难以发挥专业特长。 　　据统计，目前中国流失的留学生人才当中，科学和工程领域的滞留率平均达87%。从专业上来看，赴美留学生目前就业形势最好的是计算机专业，另外生物、物理、化学等“技术流”专业，也较易得到就业机会。而一向受国内留学生追捧的商科、法学、历史人文等专业，留在当地工作的机会则十分少。 　　 英国 　　 工程类学生保持高就业率 　　中国驻英国使馆前教育领事张艺华教授介绍，英国正面临着极大的理工科人才缺口，每年需要至少10万大学理工科毕业生，才能满足科技领域维持现状的需求，这也意味着工程类毕业生在英国将长期保持着很高的就业率。 补充 http://tech.sina.com.cn/it/2014-06-01/15229412479.shtml 中新社北京5月31日电 (记者 丁栋)伴随着IT业和互联网的突飞猛进，IT核心技术和安全问题日益凸显且迫在眉睫，中国研究机构31日发布报告称，IT核心技术和信息安全等问题已从产业上升到关系全局的战略性问题，得到更高层次的重视和关注。 　　由工业和信息化部电子科学技术情报研究所和社科文献出版社发布的《中国IT产业发展报告(2013-2014)》指出，“棱镜门”事件、 微软 ( 40.79 , -0.15 , -0.37% ) 宣布对WindowsXP停止服务、华为被美国国家安全局入侵监控等事件，都反映出核心技术和信息安全等问题的重要性和紧迫性。 　　报告指出，尽管中国在电子材料、存储芯片、导航系统、显示技术、智能语音等领域取得一定的突破，但关键信息技术和核心产品对外依存度仍较高，支撑能力比较薄弱，尤其是集成电路和基础软件关键技术受制于人。 　　报告显示，国外品牌操作系统占据中国超过90%以上的市场份额，国产数据库所占市场份额不到5%。此外，集成电路进口总额超过原油，成为中国最大的进口商品。 　　报告还指出，IT领域的知识产权竞争更加激烈，2013年上半年美国涉华“337调查”10起，居涉案国之首。如何突破外国IT企业的知识产权壁垒，成为中国IT企业所面临的挑战。(完) 【3】http://games.ifeng.com/yejiehangqing/detail_2015_05/04/41032539_0.shtml 创业感悟 □过去都是我们跑到北上广找投资人，现在是投资人来成都找我们。 □经过一轮两轮筛选，这个产业也更加成熟了。 □天使投资人是投人，他认为你靠谱，把钱给你会一点点把项目做出来。 IDG投资 IDG资本（IDG Capital Partners，原IDGVC）于1992年开始在中国进行风险投资，是最早进入中国的国际投资机构之一。至2013年，IDG资本已在中国扶植了200余家中小型高新企业，包括百度、搜狐、腾讯、携程、金蝶、奇虎360、91手机助手、汉庭、如家、九安医疗、波司登、天福茗茶等公司，已有70多家所投公司公开上市或并购。 “过去都是我们跑到北上广找投资人，现在是投资人来成都找我们”。成都槟果科技有限公司（以下简称“槟果科技”）创始人许璐，名字像女孩，人却是一名高高瘦瘦IT男，说话恳切有力。 2013年夏天，槟果科技拿到IDG的投资，许璐说这是成都手游唯一一家。在许璐看来，他能拿到IDG的投资，离不开成都手游产业的大环境。被政策推了一把后，成都手游产业集研发、运营、资本于一身，再也不是过去只有研发的“瘸子”、游戏巨头的“后花园”。在成都手游企业中，正在诞生自己的游戏巨头。 IT男玩游戏两年时间 制作300多款 创业初期连办公室都没有，电脑都买不起，借一台苹果电脑使用。我们是真的草根创业，白手起家。 许璐是游戏行业的老兵。2011年许璐创建成都槟果科技有限公司，从事移动互联网手机游戏产品制作与运营。 许璐生于1985年，2007年毕业于重庆大学。没有知名游戏公司履历，凭着对游戏的热爱与对市场的准确把握，许璐带领槟果科技活了下来，从3人的小团队成长为几十人的企业。 和许多成都手游公司一样，许璐在创立之初制作了大量游戏。两年时间，槟果制作的单机手游就超过300款。“当时有点小收入，觉得很滋润，觉得够了。” 2013年，成都手游业发展接近疯狂。当时，IT茶馆创始人王佳伦接受本报采访时说，据不完全统计，成都现在的手游开发团队有700多家。“成都手游几乎已经快到了一个疯癫的状态，什么团队都来做，什么游戏都开发，不管赚不赚钱先把游戏开发出来再说”。 这时，许璐开始思考长远发展公司，必须和资本对接。2013年2月开始和各种投资人接触。 与IDG谈15分钟 他以最快速度获投资 天使投资人是投人，他认为你靠谱，把钱给你会一点点把项目做出来。 2013年夏天，他和IDG投资人约在成都一家酒店大堂里见面。对于这次投资，许璐多次强调巧合和幸运。“我和IDG投资人交流了15分钟，他们就决定投资我们。” “当时和他讲我的长远计划。然后我也顺便讲了一下我是怎么艰难创业的，”然后，许璐向投资人介绍了一个将要做的新项目。但是投资人打断了他，说：“你不需要再讲了！”听到这句话，许璐心想：“完了，他肯定是要让我走了。”但是投资人说，“你现在不需要和其他投资公司见面了，我们来玩这个。”许璐吃了一颗定心丸。 为什么迅速决定投他，许璐说没好意思问，“天使投资人是投人，他认为你靠谱，把钱给你会一点点把项目做出来，”他笑着说，“这也说明我们在这个圈子里打磨，塑造了口碑。他们听到槟果，觉得可以为我们提供帮助。槟果也是IDG在成都投的唯一一家游戏公司，所以我们也很光荣。”许璐说。 奔着50亿估值 抛弃跟风潜心创新 幸运地获得IDG投资后，许璐不再跟风，他要创新。2015年，许璐认为他的时代来到了。 许璐与莉莉丝游戏公司CEO王信文是好友，经常一起交流手游。 莉莉丝游戏，同样是IDG投资的手游公司，它推出的《刀塔传奇》，红遍2014年，甚至打破了腾讯对App Store畅销榜的垄断，凭借这款游戏，莉莉丝游戏如今估值50亿。 幸运地获得IDG投资后，许璐不再跟风，他要创新。不碰三国、金庸武侠、西游等烂熟题材，许璐决定将街机经典《街头霸王》改成手机网游。这是一个冒险，手也是一个创新，如果手机操作能生成复杂的动作，可能就是下一个《刀塔传奇》。 进入2015年之后，卡牌手游正在逐渐被淘汰，重度手游开始慢慢攻占市场，正适合街霸题材动作手游，许璐认为他的时代来到了。“我们朝着这个方向去奋斗，至于能不能做到，交给市场去验证。”许璐对自己很有信心，拿着IDG的投资，他倾注了两年的心血在街霸题材网游，“没有理由不会成功！” 手游第四城·成都 小打小闹长成参天大树 获得IDG这种大机构的主动投资，转型做精品游戏。许璐的转变是如今成都手游行业的一个缩影。 “好几年前，成都的游戏创业者都是草根，难获资本的帮助，想发展很难。但民间资本都在北上广，所以要去北上广找他们，这是很痛苦的事情。”作为当事人，许璐感慨万分。经过前期的野蛮生长，成都手游经历几轮的筛选和洗牌。“现在有三百多家，淘汰了一部分，剩下质量高的公司，他们制作精品游戏。经过一轮两轮筛选，这个产业也更加成熟了。”成熟的产业链吸引了更多外界的商业资本入川寻找好项目。 外界大量商业资本的进入，同时将辐射并带动其他行业的发展。比如游戏测试、外包、发行和投资等等行业。“以前成都只是一个研发基地，现在形成了一个产业链。大家都把成都称为手游第四城。” 最明显的例子就是社交软件陌陌在成都成立了成都陌陌科技有限公司，主要运营包括开发软件并提供技术服务等。一位成都手游业人士感慨：“以前都说成都手游是小打小闹，如今有这么多的商业投资机构来成都，成都手游也能长成参天大树。”

个人分类: 计算机|3684 次阅读|18 个评论

[转载]软件开发模型/原型法/瀑布模型/螺旋模型

baiyunrui 2012-3-11 23:25

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型。该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。但计算拓广到统计分析、商业事务等领域时，大多数程序采用高级语言(如FORTRAN、COBOL等)编写。瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。 典型的开发模型有：①瀑布模型(waterfall model)；②渐增模型/演化/迭代(inCRemental model)；③原型模型(prototype model)；④螺旋模型(SPIral model)；⑤喷泉模型(fountAIn model)；⑥智能模型(intelligent model) ; 7. 混合模型(hybrid model) 1. 边做边改模型（Build-and-Fix Model） 　　遗憾的是，许多产品都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改. 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 　　这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于： 　　（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； 　　（2） 忽略需求环节，给软件开发带来很大的风险； 　　（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。 2. 瀑布模型（Waterfall Model） 1970年WinSTon Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 　　瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 　　瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： 　　（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； 　　（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； 　　（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 　　我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。 3. 快速原型模型（RAPId Prototype Model） 　　快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 　　显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。 　　快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 4. 增量模型（Incremental Model） 　　与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 　　增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷： 　　（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 　　（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。 　在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。 　　例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。 5.螺旋模型（Spiral Model） 　　1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。 　　螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： 　　（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 　　（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险； 　　（3） 实施工程：实施软件开发和验证； 　　（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。 　　螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下： 　　（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。 　　（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。 　　（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险 一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。 6.演化模型(incremental model) 主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。 在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。 “演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。 7.喷泉模型（fountain model, (面向对象的生存期模型, OO模型)） 喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。 8.智能模型(四代技术（4GL）) 智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言（4GL）的支持。4GL不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL（如FoXPro等）都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。 9.混合模型（hybrid model） 过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。 各种模型的比较 　　每个软件开发组织应该选择适合于该组织的软件开发模型，并且应该随着当前正在开发的特定产品特性而变化，以减小所选模型的缺点，充分利用其优点，下表列出了几种常见模型的优缺点。 模型 优点 缺点 瀑布模型 文档驱动 系统可能不满足客户的需求 快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护 增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低 螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练

个人分类: 软件工程|2956 次阅读|0 个评论

[转载]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以及钍基熔盐堆等，都投入了很大的钱。所以，虽然发生了福岛核事故，但我国核能的投入还是很多的。

个人分类: 会议交流|4176 次阅读|3 个评论

基因软件架构适合云软件开发平台的构建

Babituo 2011-10-27 22:09

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

个人分类: 基因软件开放实验室|3661 次阅读|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高校毕业生动向：北大爱金融清华爱软件 北大本科毕业生首选的就业领域为金融业（１７．６１％），而清华本科毕业生则首选软件业（２１．３０％），其次是房地产业（１３．８％），金融业（１２．２％）排第三，选择国有企业的应届生约占三成。

个人分类: 计算机|15397 次阅读|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）对计算机有强烈兴趣和天赋者不受以上限制；

5233 次阅读|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已经帮你把修改信息全部存到数据库里了。

个人分类: 科研笔记|9768 次阅读|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的糗事看似和我们的主题没多少关系，其实当中有着深刻的联系。我们前面所说的那些可以自动处理的部分，他们用人工都做得很完美，而在那些例外的地方，却几乎无例外地犯错误。那么，例外到底是什么呢？为何总是挥之不去呢？要解决这个问题，我们就需要从更深层次挖掘软件的本质。不管怎么说，软件的核心功能就是计算，那么计算是什么呢？今天互联网上充斥着各种各样的计算，仅仅用数学来概括是不足以涵盖其外延的。在数字系统之外，也存在各种各样的计算，比如模拟计算机的计算，军事上的兵棋推演，商业上的决策方法等等。如果要概括所有这些计算共同的特征，就只有三点：第一，都有一组初始的数据，代表着某个现实的或者抽象的系统在某一时刻的状态；第二，都有一组理论或者公式（或者二者兼具），规定了各个数据如何相互作用；第三，经过计算的过程，最终都得到另一组数据，描述系统在另一时刻可能的状态。如果把第一、第二两条中的要素加在一起，称之为一个模型的话，计算就相当于模型的一次推演。模型推演是人脑最基本的思维方法，人类发明计算机来分担思考的负担，因此计算机当然必须能够担负这样的计算工作。然而计算机并不懂得什么是模型，只是一个执行程序的机器，因此必须由人来将模型程序化，软件简单地说就是程序化了的模型。面向对象的方法其实就是一种模型表示法，而近年更有人提出模型驱动的开发，这都与软件的模型性质密不可分。 仅仅认识到软件具有模型的性质还不够，首先，模型本身是复杂的，虽然所有的模型都可以用一组规律加一组数据来概括，但是实际做过系统的人，特别是做行业系统的人都知道，行业知识本身就是复杂的，相互之间常常有说不清道不明的关系，如果不是自己真正理解了这些知识，仅仅以书本和专家言语为基础，做一些表面（形式化）的推理，是几乎一定会出错的。其次，初始数据也不是简单的，今天的系统，数据来源多种多样，精度、可信度各不相同，非结构化的数据常常见到，单是把这些数据转换到适合模型推演的形式，就要费九牛二虎之力。第三，模型代码化本身也不是件轻松的工作，今天的计算环境空前复杂，各种平台，各种支撑系统都要考虑，今天的架构师要掌握的知识比以往任何时候都多。最后，软件虽然以模型为核心，但绝不仅仅是模型，为了让模型进行有用的工作，各种辅助系统也必不可少。 （未完待续）

个人分类: 信息技术|6625 次阅读|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 方法论的问题，计划在今后一年当中，详细分析一下，届时敬请大家批评指正。

个人分类: 知识开发工具|2852 次阅读|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%

个人分类: 计算机|6516 次阅读|2 个评论