3、软件咨询：新兴的行业，不过要有实力和广交朋友才行。
========================================================================================================
学了一个学期的软件工程课，终于知道了个软件工程的大概。学的时候总觉得很抽象，理解起来好像不难，但总是摸不着头脑一种很茫然的感觉。学习的过程中和一个宿舍的同学一起做了个小型管理系统的开发，觉得还是有点收获的，对于开设这门课的意义也有所领悟，现在就将我对这门课的体会以及在项目开发过程中遇到的一些问题简单的归纳一下。希望在以后的学习中不断的提高吧。
曾经以为程序就是软件，软件就是程序。现在知道了二者的不同之处，这是学习这门课程第一个收获。事实上在软件开发的早期阶段这也不能说是错误的。那个时候开发的软件都比较简单。当然可以把软件理解成程序，直到软件作坊的出现，使软件在程序的基础上加了个说明。以前做过的一些小型的软件比如加密软件，我也只是在程序旁边附上一个软件的说明，看来已经很接近作坊了。不过大的项目没有接触过，用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生，使得人们不得不探索新的解决方法。
这个时候软件工程应运而生了。
我们为什么需要软件工程呢？上面已经给出了一些原因。专业点讲，软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计，没有设计指导的编程是无序的忙碌的。根据开发的软件的规模，应该适当程度的运用软件工程化的思想，需要灵活，毕竟我们开发的软件大多数是中小型的，大型的并不多见（我是这么认为的）。但只要涉及人员间的交流和沟通，或多或少都要需要软件工程才能更有效率，工作成果更稳定。
掌握软件工程化的思想 ，对于负责软件开发的管理人员（领导）更为重要。曾经看到过这么一句话，“坐在指挥台上，如果什么也看不见，就不能叫领导。坐在指挥台上，只看见地平线上已经出现的大量的普遍的东西，那是平平常常的，也不能算领导。只有当还没有出现大量的明显的东西的时候，当桅杆顶刚刚露出的时候，就能看出这是要发展成为大量的普遍的东西，并能掌握住它，这才叫领导。” 软件工程将有能力的人团结在一起，然后把他们变成工人，因为工业化的生产是效率最高的。这就是根本所在。没有软件工程管理，简直就是乱来，就好象缺乏宏观控制的国家一样，会乱七八糟。
我们已经知道软件和程序是两个不同的概念，软件除了程序还要有使用和维护该程序所需要的全部文档。包括需求文档、设计文档、测试文档、维护文档以及使用手册。
软件开发特别是大型软件是一项浩大的工程,需要几个人、十几个人、几十个人甚至几百个人合作开发几个月、十几个月甚至几年。要保证系统的协调性、统一性和连续性,就需要在开发之前制定严格、详细的开发规范。开发规范的制定需要花费一定的时间和精力,但是"磨刀不误砍柴功",它相当于把今后开发过程中开发人员都要遇到的问题提前做了一个考虑。有了开发规范,在后续的开发过程中,设计人员就不必每次考虑如何为一个字段命名,编程人员也不必去想某个程序的结构和布局应当 怎样,测试人员也有了判断程序对错的标准。开发规范在项目开发工作中起着事前约定的作用,需要所有开发人员共同遵守。它约束开发人员的行为和设计、编程风格,使不同子系统和模块的设计、编程人员达成默契,以便形成整个系统的和谐步调和统一风格,也便于今后的系统维护和扩展工作。
在实际中开发软件首先应该考虑的是是否可行的问题。但在这个实习中其实根本没必要，既然已经选好了题目，而最终也不要求能够运行，钱、软硬件资源不成问题，当然可行。主要考虑的技术问题。
下面就软件开发的各个阶段分别谈点看法。
需求分析就是要确定自己要做什么，应该怎么做，心里有个底。需求是通过与用户充分交流和自己的创造力,去发明软件规格说明的过程。如果没有双方对需求进行分析，可能出现项目设计出来的东西或最终提交的可交付物根本就不是客户所需要的，或有相当的差距。所以用户和开发人员在需求上要达成一致性。在这个实习项目中只是给了几个要实现的功能。也没有真正的用户。凭大家的想象给出一个比较好的需求有点难。
设计过程就是将你确定的需求想办法用代码去实现。这个过程是交给程序员做的。设计可能会用到很多方面的知识。软件最终的目的是要用户使用。因此在程序设计时必须立足于操作简单、实用,并真正能为用户解决实际的业务问题。不能因为怕编程麻烦而将程序功能设计得过于简陋。这个过程可能会对已经完成的需求分析做些改进甚至推翻。为每个模块确定采用的算法。然后就是根据算法写代码。以前觉得写代码是最麻烦得事情，现在才发现写代码原来只是软件开发中最简单的一个步骤。到目前为止学了C，C++，还有java，熟悉的还是面向过程的C，面向对象的软件开发还有待于实践。在这个小项目的开发中因为没有要求写代码，所以也没有使用哪种程序设计语言的问题。但我想既然面向对象的软件开发有着比传统的开发无法比拟的优点加上现在java风靡全球，连比尔盖茨都说java是目前为止最优秀的计算机语言，学着用java开发感觉好点。看来以后要好好的学java了。
软件交付之前必须要测试。测试是保证程序质量的一项重要工作。但测试只能证明程序有错,而不能证明程序无错。所以任何软件系统都不能保证内部没有错误。为了确保软件系统的安全与可靠性,一方面要加大测试力度,另一方面要抓住测试重点。程序又是测试的重点。一个合格的测试员应该很熟悉别人的思维。但感觉程序员应该很反感测试员。软件开发是一项建设性工作而软件测试是一项破坏性工作。一个曾经做过测试的如是说，“做测试，我感到最多是在和程序员在吵架”。我觉得测试的基本要求就是找出产品的缺陷，用简单明了的方式表达给开发人员，心平气和才好办事。不管怎样，有了破坏才能使软件的免疫能力强起来。测试占了开发一半以上的时间和资源。
我在实习小项目中做的是测试的工作。由于没有源代码，所以只能做静态测试。测试过程感觉很不好。摆在我面前的只有个软件需求文档和详细设计文档，而且需求分析一大半也是我写的。现在才发现需求分析当时写的有多么的差劲。很多的问题都没有考虑到。而且发现设计文档中的软件初始结构图根本不是按照需求分析给出的数据流图转化过来的。详细设计文档呢，跟总体设计差不多，甚至连总体设计的一些要求都没有，比如接口的描述，从头到尾没有提到过。面对着那份详细设计报告，我无从下手，什么都没有。每个模块的细节都没有考虑。还是一个最最基本的框架。可事到如今又能怎么办，总不能把原来的抛弃自己在测试之前重新做个详细设计吧，只好硬着头皮测了。测试完成后感觉没一点收获。还不如看看书上的白盒子测试的例子体会多一点。报告打印了一点成就感没有。
软件维护是软件生存期中的最后一个阶段。实习没有这方面的要求。维护也不像其前面的几个阶段理论成熟。但维护不是一天两天就能解决的问题。自从软件开始工作，维护就从来没有停止过。所以维护是一个耗人力物力最多的一个阶段。具体维护的方法应该根据软件的开发方法来具体确定。维护是为了软件能健康准确更好的运行，但在维护的同时也可能因为开发方法的缺陷导致维护产生一大堆的副作用甚至可能使得情况变得更糟，会得不偿失。所以维护马虎不得一定要慎重对待。
总的来说，软件工程还是门不成熟的学科，在很多方面有不尽人意的地方，它在软件开发领域的作用还没有充分的发挥出来。尤其在我国，软件产业发展滞后，只占国民经济的很小一部分。听说在美国，软件产业在国民经济中的比重仅次于汽车产业。我从一些国内的一些论坛上考到有些程序员总抱怨说公司开发软件根本不重视软件工程的技术。所以有些人说软件工程没有用处。但我想随着软件规模的日益壮大，软件工程技术一定会越来越受到开发人员的重视。当然软件工程理论的成熟还有待于IT界广大软件开发人员的共同努力，需要从实践中摸索规律总结经验，但可以相信软件开发工程化的思想绝对是先进的，科学的。相信以后软件工程的技术和理论会为大型软件的开发做出更大的贡献。同时更希望我国的软件开发者们为我国的软件产业的发展做出杰出的贡献。
====================================================================================需求分析：
不是具体的解决问题。而是准确地确定软件系统必须做什么，必须具备哪些功能等问题。
概要设计：
主要任务是确定软件的总体结构和数据结构，并定义模块间的接口。也就是确定该软件系统有哪些模块组成，每个模块的功能是什么，这些模块的调用关系是怎样的。同时还要设计总体数据结构和数据库结构，即软件系统要储存什么数据，这些数据的结构及他们之间的关系等。
详细设计：
主要任务就是给出总体结构中每个模块完整的算法描述，把功能描述转变为精确的结构化的过程描述。即该模块的控制结构是怎样的，先做什么，后做什么，有什么样的条件判定，有什么重复处理等，用相应的表示工具把这些控制结构表示出来。
编码：
就是把详细设计说明书中每个模块的控制结构转换成计算机可接受的程序代码，即按照选定的语言，把设计的过程性描述翻译为源程序。
测试：
测试按不同的层次可分为单元测试、组装测试、确认测试和系统测试几个步骤。
单元测试是查找各模块在功能和结构上存在的问题；
组装测试时将各个模块按一定顺序组装起来进行的测试，主要是查找哦啊各模块之间接口上存在的问题；
确认测试时按说明书上的功能逐项进行的测试，决定开发的软件是否合格、能否交付用户使用等。
下面是在水木软工上的对话。有兴趣的可以看看，全文涉及工程与科学之间的差异，软件工程的工程本身的分析，项目经理的行为和强弱势项目经理的一些问题。
btw：里面有著名的钱五哥的回复，呵呵。
☆─────────────────────────────────────☆
别笑我弱大家讨论讨论，呵呵
我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
正意义。
我能想到的就是"more pratical"和理性。因为在我的理解中传统的工程(就是类似于建小区
)的产物都是实证的都必须是可行的都必须是经得起考验的。与之相对的就是夸夸其谈的艺
术的创意的只需要设计不重实现的，这些方向要的是纵横捭阖天马行空。
两项相较：一边是海水一边是火焰，一边是理性与冷静，一边则是感性与激情。一边是控制
一边是纵情。
而我们研发软件，同建房子一样，不仅要设计，更要能实现。最终的工件必须是经过客户用
户检验的，这个检验也是有标准的，不存在公说公有理婆说婆有理的情况。
软件工程的提法反映了当时软件开发屡遭失控打击的形势下，永不停止学习的软件人向传统
行业借鉴经验的决心。自此之后，估算技术测量技术地位急剧高升?
各位是怎么理解这个软件工程中的“工程”的？有没有人讲讲来龙去脉，freestyle。^_^
但是软件工程中有方法论过程论，这算不算传统工程理论的一部分？
☆─────────────────────────────────────☆
qingrun (青润) 于 (Thu Jan 14 21:10:42 2010) 提到:
不弱。能深入思考工程两个字的含义是很有必要的。
不思考工程两个字就来做软件开发的人，容易形而上学，更容易僵化的处理新的概念和新的方法论，借用老毛同志的话就是，容易本本主义。呵呵
不过，你这个话题太大，bbs上做这样的讨论，需要大量的文字输入，得不偿失，呵呵。
辩论或者讨论的时候，思辨过程和响应回路过长，价值不大，这样的问题应该考虑别的讨论形式会比较好一些。
【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
: 正意义。
: ...................
☆─────────────────────────────────────☆
blueslc (Thomas) 于 (Thu Jan 14 23:04:41 2010) 提到:
Engineering is a cooperative game of invention and communication.
from <Agile software development - the cooperative game>
这本书有一章讲工程和软件工程，说的很好，我试着重复一下看看了。
过程中有创新的才是工程，没有的话就是生产而已，在传统领域，很多工程其实只是生产而已，没有什么难度。比如造房子，造第一座房子是工程，如果造同样的第二座，那就是生产。造第一座的难度，肯定比第二座要大很多
软件由于其独特性，每一个软件都不一样，所以软件工程，要和你造第一房子作对比，而不是第二座。
【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
: 正意义。
: ...................
☆─────────────────────────────────────☆
qingrun (青润) 于 (Thu Jan 14 23:23:36 2010) 提到:
这个对比似乎应该是科学研究与工程对比，科学研究是造第一座房子，然后工程才是重复后面的房子过程，呵呵。
我个人认为，这本书里面讲的这个工程的解释应该是完全错误的。它混淆了科研与工程之间的差异。
☆─────────────────────────────────────☆
qingrun (青润) 于 (Thu Jan 14 23:27:44 2010) 提到:
评论一下这句话：但是软件工程中有方法论过程论，这算不算传统工程理论的一部分？
我记得我的blog上有一片关于软件工程重新定义的文字上（我对软件工程领域划分的认识之一，地址：http://blog.csdn.net/qingrun/archive/2006/12/21/1451598.aspx ），和一个在河南某大学的老师产生了争论，通过评论和评论回复的方式争论了几乎一整天，其实说的就是一两个小时就可以说完的东西。
对这个话题以及这个话题中各方面包含的内容做了比较深入的讨论。
☆─────────────────────────────────────☆
qlw (钱五哥) 于 (Thu Jan 14 23:43:55 2010) 提到:
工程和技巧相对应。工程的基础是可以测量，曾经复印过一张施工队的进度和报价
上面将投入、工时、成本算的清清楚楚。这和动辄可能延期的软件开发有天壤之别
但是软件工程也是很困难的，测量到现在似乎也没有什么人提出来与时俱进的方法
工程化最终导致了文档化和僵化。因此出现了敏捷过程 - 出发点是简化传统的工程
思路，从而回归到产品化的正确道路上。但是在解决规模扩大的问题方面还是有
些问题。早一些的CASE、组件化、软件工厂等概念，虽然盛极而衰，但是留下了
包括pattern、UML在内的遗产，对工程化有不小的帮助。
工程化首先要求可以重用，如果至今一直用主机+Cobol+DB2，则我坚信现在已经
工程化好久了，可惜目前是Linux+虚拟化+云计算的时代，原先搞的那套玩意早就
过时了，工程化还受到技术成熟性的制约！
可以看看Gartner的Hyper Cycle，现在M2M已经开始预热了。看到这类玩意，不禁
心说，“工程化又远了”
供讨论
☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Thu Jan 14 23:58:08 2010) 提到:
我再讲些感想。
软件工程是如此的复杂，风险是如此的高，搞到65%的软件项目延期，30%的项目直接取消。
跟传统工程的按时交付率差别如此之大。
原因有二：
第一是软字，软的就像女人的奶子客户都想捏成自己想要的形状。很多客户都不知道达到随便捏的程度需要吃多少木瓜，这种客户和软件提供商的沟通有点巴别塔。
其 二在原软件工程固有的复杂性。传统工程正如我开始所说，设计和实现相分离，劳斯莱斯的design和implementation是完全个裂开的。而软件 项目中design和implementtation是如此的不可分家，每一个实现者都在自己的范围内进行design。
和传统工程比 较，软件工程的轨迹必然是守破离。大乱时代，我们需要一个框架，是以学习传统工程，但由于上面两点，慢慢的，软件工程变异出自己的特性，我认为这里可以分 为三个层次：过程论/方法论/最佳实践和反模式，这些都是那些重视测量估算的传统工程所没有的。慢慢的最终发展出自己的一套理论，和传统软件工程完全不同 的理论。在这里，测量不是最重要的，最重要的是革新，是重构，是抽象，是沟通是融合而不是分而治之不是人为构筑壁垒。
☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:21:24 2010) 提到:
那肯定啊，但是主要指导思想还是IOC和分而治之。
说起这个就想起而二战的通用，短时间内就是用IOC理念造就了如此多的飞机。。。。
【 在 canper (洗衣粉) 的大作中提到: 】
: 车盲，不了解，不过我想造车设计师也不是画完图纸就完事的吧，也要参与样品车的组装，调试。
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:26:47 2010) 提到:
我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。
我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 那肯定啊，但是主要指导思想还是IOC和分而治之。
: 说起这个就想起而二战的通用，短时间内就是用IOC理念造就了如此多的飞机。。。。
☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:31:14 2010) 提到:
我觉得软件行业革新的动力就是融合互相学习无法剥夺的学习，而传统行业是分而治之，缺乏对流缺乏沟通。软件行业如果没融合没沟通，基本上就夕阳了。
我们之所以如此热爱这个行业，就在于我们喜欢沟通交流喜欢持续改进而不是得过且过。
【 在 canper (洗衣粉) 的大作中提到: 】
: 我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。
: 我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:32:05 2010) 提到:
不过同样的事情如果放到建筑业就不是那么回事了，设计师画完图纸就完了，没有必要建一栋房子来验证自己的设计。
如果是服装业呢，好像也要做出样品来看看效果。
【 在 canper (洗衣粉) 的大作中提到: 】
: 我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。
: 我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:33:10 2010) 提到:
这个，我还真说不上热爱
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 我觉得软件行业革新的动力就是融合互相学习无法剥夺的学习，而传统行业是分而治之，缺乏对流缺乏沟通。软件行业如果没融合没沟通，基本上就夕阳了。
: 我们之所以如此热爱这个行业，就在于我们喜欢沟通交流喜欢持续改进而不是得过且过。
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:35:22 2010) 提到:
在考虑一个问题，一个好的汽车工程师不需要拥有技师的技能。
一个好的服装设计师不一定是个好裁缝。
但是一个好的软件设计师不是一个好的编程人员就不靠谱了
【 在 canper (洗衣粉) 的大作中提到: 】
: 不过同样的事情如果放到建筑业就不是那么回事了，设计师画完图纸就完了，没有必要建一栋房子来验证自己的设计。
: 如果是服装业呢，好像也要做出样品来看看效果。
☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:36:00 2010) 提到:
这就是软件业的design和implementation不可分离的特点啊。
【 在 canper (洗衣粉) 的大作中提到: 】
: 在考虑一个问题，一个好的汽车工程师不需要拥有技师的技能。
: 一个好的服装设计师不一定是个好裁缝。
: 但是一个好的软件设计师不是一个好的编程人员就不靠谱了
: ...................
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:38:02 2010) 提到:
但是一个好的软件工程师不需要是一个好美工，哈哈
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 这就是软件业的design和implementation不可分离的特点啊。
☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:39:49 2010) 提到:
这里的design不是指UI design,而是指 architecture啊。
【 在 canper (洗衣粉) 的大作中提到: 】
: 但是一个好的软件工程师不需要是一个好美工，哈哈
☆─────────────────────────────────────☆
qingrun (青润) 于 (Fri Jan 15 14:25:48 2010) 提到:
这 样的实验我做过，02年8月，南京地税金力四期项目上，我从上海带了5个人过去参加tp当年的团队，后面给了我两个星期做一个模块实用性原型，成都那边给 了我一个美工，我这边自己做模型开发，设计完成后，分给了一个做页面，一个做数据库，我做业务控制层，一个人做银行接口的扣款，一共8天不到全部搞定，一 次性通过测试。
做界面和数据库开发的人完全是在我给定的模型导出的代码上进行的，我们做了一次设计变更，形成了一个独立的直接对象数据的写入类。
所以，我一直定义的编码人员就是印度的那种编码层次就足够了。
不是说设计人员完全脱离编码，而是对于一些创造性和创新性或者说有一定难度的编码是需要设计人员写好的，类似于过去传统软件工程中提出的微代码的开发阶段所完成的内容。
这样，就可以完整地实现代码设计的分离。实现我们的对印外包。
【 在 canper (洗衣粉) 的大作中提到: 】
: 我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。
: 我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。
☆─────────────────────────────────────☆
qingrun (青润) 于 (Fri Jan 15 14:28:53 2010) 提到:
一个好的汽车工程师也需要好的技师的配合，在做一些设计的时候，需要他们才实现设计，然后进行验证，获得验证结果后，对设计进行调整和优化——我的本专业材料学就是干这个的，现在大多数同学都在汽车行业，嘿嘿。
【 在 canper (洗衣粉) 的大作中提到: 】
: 在考虑一个问题，一个好的汽车工程师不需要拥有技师的技能。
: 一个好的服装设计师不一定是个好裁缝。
: 但是一个好的软件设计师不是一个好的编程人员就不靠谱了
☆─────────────────────────────────────☆
qingrun (青润) 于 (Fri Jan 15 18:10:17 2010) 提到:
不管我们做什么软件，这个软件大部分都是此前已经有人做过的，或者有过类似的，或者至少是在原理上已经被证明过的，如果非要强调，应该说，科学是对原理的验证，而工程是对原理的实现。
难度有可能实现比推理过程更难，所以，在科学领域的很多学科上都有大量至今还无法验证的假设，这是客观存在的，假设往往需要很多条件满足后才可能被验证，所以，那本书上说的工程的所谓概念是完全错误的！！！
【 在 blueslc (Thomas) 的大作中提到: 】
: 但对于软件开发，对开发者来说，我们经常都是在造第一座房子，有时候还是在原来房子的基础上加层，更加困难
☆─────────────────────────────────────☆
ilovecpp (cpp) 于 (Fri Jan 15 23:48:23 2010) 提到:
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 我再讲些感想。
: 软件工程是如此的复杂，风险是如此的高，搞到65%的软件项目延期，30%的项目
: 直接取消。
: 跟传统工程的按时交付率差别如此之大。
传统工程真有这么牛？
787的延期，Larabee的延期，业界巨头数十亿美元轻易打水漂。
一部美国军机发展史，就看见三个词：延期，超出预算，项目取消。
软件工程喜欢拿盖房子作比。盖房子真是这个时代最接近软件工程的传统工程？
我父母是电子工程师。我的直观印象是，电子产品的开发决不像盖房子，倒是和
软件开发的过程颇多相似之处。
和传统工程比，我们做得真的更差吗？
诸多疑问，难以厘清。
☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 11:23:17 2010) 提到:
对 于国内来说，我们和国外的差距主要在管理意识上，而不是技术层面；由于管理意识的差异，引起的投资方对软件系统的渴望和要求有了非常大的变化，国内的传媒 方面对国外软件项目的报道，也包括国外对自己的软件工程实施的报道也都大多集中于成功的例子，加上随着大家对科技进步的奢望，总认为软件应该能做到什么什 么样子，应该能解决什么什么问题，却忽视了软件本身最需要解决的根本问题：数据积累。
国外的软件行业走过了超过我们三倍以上的时间，他们积累的数据基础远远不是我们目前能够比拟的。
对 美国来说，因为几次世界大战都没有到他的本土，他的企业和经济的延续性在全世界范围内都可以算是最好的，其数据的保持也是最好的，而我国，大部分企业都是 80年以后重建的，更多的数据在二战，文革中全面毁灭，没有剩下什么，我们所能研究到的数据积累能超过10年的都不多，而且大部分是未信息化处理的原始数 据，但是同时，国内的宣传为了获得眼球的注意力，更多的关注在国外已成功地项目和目前的技术积累和产品状态下，所以，附带而来，传统行业在信息化的时候对 我们的期望就处于一个相对过高的水平线上，于是就带来了意识与技术现实的直接冲突，加上可投入研发资金和积累的时间问题，于是这个矛盾就更为剧烈了。
所以，不是我们做得不够努力，而是环境太过于苛刻了。
虽说解决这些问题不是不可能但是，需要多方面的配合和引导，涉足点太多，就超出了这个话题了。呵呵
☆─────────────────────────────────────☆
blueslc (Thomas) 于 (Sat Jan 16 11:40:07 2010) 提到:
那软件的开发算是科学？还是算是社会学？很多事情都没有这么绝对的。
【 在 qingrun (青润) 的大作中提到: 】
: 不管我们做什么软件，这个软件大部分都是此前已经有人做过的，或者有过类似的，或者至少是在原理上已经被证明过的，如果非要强调，应该说，科学是对原理的验证，而工程是对原理的实现。
: 难度有可能实现比推理过程更难，所以，在科学领域的很多学科上都有大量至今还无法验证的假设，这是客观存在的，假设往往需要很多条件满足后才可能被验证，所以，那本书上说的工程的所谓概念是完全错误的！！！
☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 11:56:03 2010) 提到:
软件开发是工程学的内容，绝对不是科学领域直接关联的内容，当然，一切都是在科学理论的指导或者指引下完成的，这个事情，可以说是绝对的。
科学的概念和范畴是可以明确地东西。这个问题也是可以明确地，呵呵。
【 在 blueslc (Thomas) 的大作中提到: 】
: 那软件的开发算是科学？还是算是社会学？很多事情都没有这么绝对的。
☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Sat Jan 16 12:20:57 2010) 提到:
说起这个来，确实在管理意识上有些不匹配，举个很弱的例子
我以前有个非it的老大，买了个2w的asp源代码，后来几个项目非要我用这个asp源代码，一个项目下来用“不要改”阻击了我起码快20次提议。
他很难理解有现成的东西为啥不用，仿佛另起炉灶或者升级给就算是把他那小2w给浪费了会给他造成很多成本费用似的。虽然我解释过很多次。
搞软件有时候对成本对质量的贡献，管理人员在管理层面上过程成层面上的运作不见得比技术人员关键。
此时，我想起一本书（应该是《软件工程的事实与谬误》）前言中提到作者说过的一句话，大意是说他喜欢搞技术，很享受这种技术人的意见压倒管理者命令的状况。当时我觉得很好笑，我心想在中国你有立锥之地吗？
☆────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Sat Jan 16 12:22:05 2010) 提到:
昨晚上看到一本用友人写的书，说很多技术顾问不愿意跟着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..
【 在 canper (洗衣粉) 的大作中提到: 】
: 我就一个写代码兼做工程的，整天和客户打交道
☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 12:25:42 2010) 提到:
我去年年初就拍死了一个合作公司的市场，对技术人员太不尊重了，后来他们还过来找了我一次，希望我继续提供咨询和培训，我没理他，就没有再找我了。
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人写的书，说很多技术顾问不愿意跟着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..
☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 12:26:50 2010) 提到:
所以，在中国，有技术基础，又能谦虚做事的项目管理人员才可能把项目做的很好，单纯的强势或者弱势项目经理都是不好当的。呵呵。
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 说起这个来，确实在管理意识上有些不匹配，举个很弱的例子
: 我以前有个非it的老大，买了个2w的asp源代码，后来几个项目非要我用这个asp源代码，一个项目下来用“不要改”阻击了我起码快20次提议。
: 他很难理解有现成的东西为啥不用，仿佛另起炉灶或者升级给就算是把他那小2w给浪费了会给他造成很多成本费用似的。虽然我解释过很多次。
: ...................
☆─────────────────────────────────────☆
keygen (贫贱夫妻百事哀) 于 (Sat Jan 16 12:29:09 2010) 提到:
技术牛的项目管理人员强势点，大家倒是很愿意接受的。哈哈
【 在 qingrun (青润) 的大作中提到: 】
: 所以，在中国，有技术基础，又能谦虚做事的项目管理人员才可能把项目做的很好，单纯的强势或者弱势项目经理都是不好当的。呵呵。
☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 12:34:02 2010) 提到:
那样会有一个问题出现，而且这个问题根本无法解决，那就是：
如果团队内有一个差不多一样牛的技术人员存在的话。
我曾经在自动化所跟随过一个技术很牛的研究员，离开后，写了一系列好像是五篇相关文字在我的blog上，就是谈如何和一个纯技术的老板合作的话题。
和他的合作就存在一个很严重的问题，那就是：他情商太低，低到了公认的负值——有人说这还不够。
一个例子08年底到09年中期，他发生了两次学生集体叛逃的事件，第一次18个学生9个集体提出换导师，其中有两个博士，是我在的时候的弟兄，人很老实，都已经博士第三或者第四年了，你想想，能把人家压迫成什么样子才能逼人家做出这样的选择。呵呵。
技术上大家都服气，都认为他很牛，我出来后，提到他也都说，他技术上的确很牛，别的，大都一带而过，偶尔用类似上面的事件作证明来说明一些，呵呵。
【 在 keygen (贫贱夫妻百事哀) 的大作中提到: 】
: 技术牛的项目管理人员强势点，大家倒是很愿意接受的。哈哈
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Sat Jan 16 13:41:40 2010) 提到:
没有，每次出来他们都使劲的和我说这是很健康的事情，不要想歪了等等。
天地良心，我从来都认为这是很健康很健康的事情，但是健康的事情多了去了，又不见得一定要做。话说每星期打羽毛球我都没去，怎么就没人来和我解释：打羽毛球是很健康的事情。
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 所以你在洗脚房里睡觉，他们估计在嘀咕:难道是要把妞送到他房里去? @_@
: 开个玩笑。
☆─────────────────────────────────────☆
SPQR (苍狼) 于 (Sat Jan 16 17:52:51 2010) 提到:
这是因为不会说话啊...
做销售的, 何至于这么不会沟通
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人写的书，说很多技术顾问不愿意跟着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..
☆─────────────────────────────────────☆
SPQR (苍狼) 于 (Sat Jan 16 17:54:29 2010) 提到:
打羽毛球是很健康的事情
【 在 canper (洗衣粉) 的大作中提到: 】
: 没有，每次出来他们都使劲的和我说这是很健康的事情，不要想歪了等等。
: 天地良心，我从来都认为这是很健康很健康的事情，但是健康的事情多了去了，又不见得一定要做。话说每星期打羽毛球我都没去，怎么就没人来和我解释：打羽毛球是很健康的事情。
☆─────────────────────────────────────☆
finely (finely) 于 (Sat Jan 16 20:55:03 2010) 提到:
你们都喜欢发长文 啊
我说个简短的，主要就是“工程”和“研究”之区别
工程就是干活，理论和工具都是现成的，用就是了
研究是高难度的创新，是制造理论和新工具的
软件从本质上讲，是个工程，但是一个复杂度极高的工程，以至于很难控制，所以需要一些理论和方法来控制这个工程。
【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
: 正意义。
: ...................
☆─────────────────────────────────────☆
SPQR (苍狼) 于 (Sat Jan 16 22:43:39 2010) 提到:
有意思
所以工程大致是(关键字)
1) 应用/制造 (输出是可以直接使用的实物)
2) 系统化的/方法论的
不是;
1) 研究 (输出是研究报告)
但是其实工程这个概念是不需要严格界定的
【 在 finely (finely) 的大作中提到: 】
: 你们都喜欢发长文 啊
: 我说个简短的，主要就是“工程”和“研究”之区别
: 工程就是干活，理论和工具都是现成的，用就是了
: ...................
☆─────────────────────────────────────☆
zhangmike (秦月) 于 (Sun Jan 17 08:21:43 2010) 提到:
正确的短文的产生 是先有长文，再提炼,提炼完了后，短文就不完全对，一般95%的情况下是对的。还有5%的特殊情况下就不对。
然后就又有讨论和争论，焦点在5%的部分。
所以有时间也可以看看长文。
原文地址：http://blog.csdn.net/u013467442/article/details/41699125
