• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

对软件工程的几点思考

发布: 2008-9-17 09:37 | 作者: 不详 | 来源: 测试时代采编 | 查看: 57次 | 进入软件测试论坛讨论

领测软件测试网
关键字:软件工程 思考

软件工程是近些年来在计算机领域中非常活跃的一个学科。对从事软件开发的人员来说,“软件工程”毫无疑问是一个时下出现频率非常高的字眼,对于我们许多IT人而言,如企业领导者、项目管理负责人,或是其它各种不同职位的软件技术人员,我们经常都会有意识或无意识地提到与软件工程相关的许多字眼,诸如RUP敏捷软件开发方法、UML,或是CMM等。是啊!由此可见,在我们的潜意识里,软件工程不仅很重要,它也的确很Fashion!
当然,时髦归时髦,时髦大多时候也许是感性的,它不一定会很科学和合理。因此,我们不禁要大声地反问自己:软件工程究竟给我们的项目(尤其是那种大型的软件项目)开发和实施,带来了多大的变化呢?例如,它能够给我们的项目节约了多少成本?对我们软件产品质量的提高起到了多大的作用?还有就是,它又能够规避了多少项目的风险等?
 
在实践中,也许我们的许多项目对上述问题的回答并不值得乐观;甚至很多时候,软件工程对我们项目的影响还会是负面的。那么,这里又不禁要问:为什么在软件开发领域中应用工程化管理方法后,就不能够像许多其它工业领域中那样应用工程化管理方法之后,能够发挥出更大更积极的作用呢?
 
对于上述问题,也许我们每一个人都可以轻松得出一个大概一致性的结论:这是由于软件开发是属于高技术含量的产品研发过程,它不同于其它一些比较普通的工业产品在开发过程那菀捉锌刂坪凸芾恚欢彝恢掷嘈偷牟飞鞒桃埠苋菀妆挥行У馗粗剖褂谩6砑返目ⅲ行矶嗥渥陨淼囊恍┨厥庑裕绾芏嗷方诙际谴丛煨缘闹橇投衅湮ㄒ恍裕枨蟛蝗菀兹范ǎ蛐枨缶8惶斓忍氐恪?lt;/DIV>
 
客观的说,上述的结论基本上阐述出了问题的实质。但是本人认为这样的结论太过于笼统,或者说,它没有阐述到问题的具体关键点上。因此在本文接下来的内容中,我试图,也可以说是胆大妄为地,来阐述出自己对此的一些独到理解和观点。也许这其中的诸多观点可能会有些偏颇,值得大家来进一步商榷。这是因为我本人既没有对软件工程进行过系统的研究,不是自称为是这方面的专家,也没有一箩筐又一箩筐对软件工程的实践,更不是具备那种与生俱来杰出天赋之人。但是,我相信我会有属于自己的一份的自信,再外加上一份自己特有的成长、教育、学习和工作经历 —— 在农村长大,后进入城市学习和工作,在属于事业单位性质的医院实习过一年,后又在处于改革风口浪尖的国企工作过6年,近5年又漂泊在异乡为处于市场机制下运行的私企和外企给辛苦地打工;做过推销药品的业务员,也曾在办公室里安安静静地工作过,还从事过会计;虽在校所学是药学专业,后决定毅然转行,系统地自考过经济学专业课程,最后居然完全靠自学,而进入了计算机软件开发行业内工作,并保持到至今;喜欢哲学,勤于思考,酷爱动手,常常莫名地拥有“打破沙锅问到底”的那一股韧劲。所以,凭着这独特的一份人生阅历作为背景,我在这里主要从经济学和软件技术的视角,来对当前软件工程应用不甚理想的状况展开了几点深入的思考,真诚地希望能对我们以后的软件业发展有点参考价值,或能给大家一些有用的启发。当然,如下文中的某些观点能获得更多的有识之士认同,或能够产生一些共鸣,那将是本人的最大荣幸。
 
毫无疑问!“工程化”不是软件开发行业所独有的,它是工业革命(或者说产业革命)的产物。软件开发行业引进工程化的管理方法,也即软件工程,它当初的目的是为了解决软件危机。而造成软件危机的主要原因是由于软件项目的规模日益快速扩大,而规模宏大的软件项目必定会需要更多、更多的人来齐心协力的共同参与。因此从本质上说,软件工程研究的内容其实很简单 —— 那就是,软件开发人员如何更好地在一起协同工作,以便能够共同完成某一项规模宏大的软件产品的开发任务。就好像蜜蜂协同建蜂巢那样,这当中需要科学的方法和科学的管理,以及很好的协同和分工。因此软件工程实际上必然会包括很多很具体的一些东西,如任务的分工和协作、开发过程方法、计划与进度控制、质量保证、成本控制与资源分配等等。在这里,我本人不太感兴趣对这些具体的东西展开过多讨论,而是重点围绕在工业化革命中,对工程化管理思想带来革命性进步的一项技术方法 —— 产品的流水线作业展开分析讨论。
 
我个人执著的认为:“如果没有流水线作业技术,根本就没有后来的如此发达的工业社会文明”。这样说其实一点也为不过分。我们也许不敢说流水线作业技术是最好的分工和协作方式,但是毫无疑问,它却是至今为止最为行之有效的一种分工和协作方式。它把无论多么复杂的制作过程进行拆分,一步一步的,直至它很简单为止。这样,流水线作业技术就使人类自身获得了较彻底的解放,一个人再也不用去掌握那么多的技能。这不仅是提高了效率,也更提高了产品的质量。而且这样被拆分后的每一个简单工作任务,可以很容易地让机器去代替完成,从而大幅提高生产效率并降低生产成本。同时,对复杂过程进行最大程度上的细分后,能有效的实施无关联步骤的并行开发活动,从而大幅缩短每件产品开发所需的时间。
 
如果我们从一个更广义的视角来审视软件工程;那么软件工程其实可以被理解为,是对软件的开发活动,如何来实施流水线作业化的拆分过程。这个流水线作业化如果实施得好,那么可以说对这个软件项目的工程化,肯定也是实施得很成功的。80年代盛行的结构化分析和设计方法中的瀑布模型,它基本是遵循完全线性化的工作拆分流程,和其它的工业产品的生产流程类似,前一个“工序”没有被完成并审核通过,后一个任务流程是不会启动的。当然,后来发现,这样僵硬死板的软件工程化开发流程,其实对许多项目并不适合,尤其是那些需求从一开始很难确定的项目,或是需求变化太快的一些项目。因此,后来在软件工程领域中,出现了许多其它的一些软件开发方法,诸如原型法、迭代法、螺旋法、演进法等等。
 
上面的这些不同的软件工程化开发方法,这些都是由于软件开发这一领域的本身独特性所致,前面也阐述过这一点。但是真正导致当前软件工程应用不甚理想的原因,就仅仅是因为如此吗?就完全是因为软件开发其自身根本不适合采用工程化的思想来管理吗?不!本人决不赞成这种观点,虽然我也认为,由于软件开发领域中每一个工作任务都需要很大的创新性等诸多特点,它会很大程度上影响软件工程化的实施难度;但是,这一点我们通过不断的实践,不断的改进,以及软件技术本身的发展,其实我们是可以有效地克服这些困难的,后面会进一步阐述与此相关的一些技术的演进过程。而我认为,更为关键的原因是我们社会,或者说是我们人类自己的一些缺点所导致的,是我们的思想文化上的狭隘和片面追求利益之上的情结所造成软件工程很难突飞猛进。为何这么说呢?
 
试问!其它的工业产品在其完整生产周期过程中,会只有一个厂家参与某个产品生产的全过程吗?很明显,绝对不是这个样子的。我们知道除了原材料之外,中间还有许许多多的中间产品(半成品)环节。试想!如果一个房产建筑商在承建某一栋大楼时,所有的东西,所有的任务都由它一家公司来做,这可能吗?它又要去生产钢筋,又要去生产水泥,它还有能力去造楼吗?所以这就需要社会分工。而“流水线作业”,也绝对不是狭隘仅指,你某个公司内部有很好的流水线作业管理就能够行得通!而是一个某行业的、甚至是全社会的合理分工和协作。
 
但目前的软件行业却并非如此,看看那些个软件巨头们!它们几乎都是独成一个体系,什么软件包都是自己做,很少去依赖于别人。当然,在此也许大家会觉得不以为然,实际不是这个样子呀!软件开发厂商之间也有很多的合作呀!而且对于应用软件系统的开发商或集成商,它们会觉得有许多开发平台,以及很多很多的可复用的开发库可以利用。这些“开发库”不就是相当于其它工业产品中的半成品吗?
 
本人不敢苟同上述的这种意见!因为这些所谓的“开发库”是完全封闭的、并受某个厂商单向控制并垄断的。所以它有很大的不确定性,例如,对这些库的整体结构设计,或者某个接口的设计,作为使用者你,你有权去修改它吗?可能连建议权也没有吧!另外还有就是,当开发库在升级时,你的应用程序很可能存在由于接口不一致性所带来的巨大风险!也许又有朋友认为,你可以使用那些开源项目的开发库呀!那么我又请问?此时你的软件产品质量由谁来保证,如果某个库中的某个bug导致了你系统的崩溃,你能及时找得到谁是真凶吗?即使你找到了真凶,你还能找得到某人或某软件开发商来为此来负责吗?
 
所以说,现在的软件开发领域,它这里缺乏一个很好的产业链环境。缺乏像其它工业产品中的“半成品”式的复用,虽然我们曾经对组件的搭积木开发方式寄予过很美好的希望,还有ActiveX控件等。究其原因,就是由于各个软件公司为追求利益最大化,梦想自己垄断并主宰整个(或某类)软件产品的全部规范及开发过程;其结果导致软件工程的思想很难全面实施,最终也必将影响各个软件企业间的合作,并影响软件产品的开发效率。这里我们再举一个例子。两个企业厂商,一个从事PC的组装生产,而另一个从事企业应用软件的集成(EAI),您认为,这两个企业所从事的工作,那一个更容易、更简单呢?我们不能说PC机的里面的构造会很简单吧!它里面那么多电路板和那么多精密元件,但是由于它的任务分工很好,模块化程度很高!所以最后做组装和集成的时候,就很容易进行。而从事EAI的工作任务时,本来这毫无疑问是很简单的一件事,但是由于各个应用之间缺乏规范和合作,使得本来很轻而易举的一件事,未必就会那么被轻易地搞定。
 
在文章最后的一段内容中,我不想在这里再过多评论现在的软件工程技术的一些是是非非,而是给出一个俺本人认为较为理想的软件工程实施模型,也许这个模型过于理想化,甚至是很不成熟。但是我会执著地认为,我们的软件工程应该朝这个方向去努力。
 
要想软件工程真正能够像其它产业中的工程化应用那样发挥出更多更好的作用。那么,首先就一定要注意培育出一个好的、健康的软件开发的产业链环境。只有这个产业链环境健康了,成熟了,各个软件企业才会有更多的资源去关注属于自己擅长的那一块工作任务,也才可能把属于自己的工作任务真正地去完成好。当然,这样各自的软件企业在这个大的软件产业链环境中,必定会找到并实现自己的最大利益。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 软件工程 思考

21/212>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网