软件工程实习(一)
在这次软件工程课程中,我学到了很多东西,第一次深刻的体会到了什么叫做用工程化的思想来编写软件,以前自己也写过一些小型软件,没有做过大型的项目,直到这次课堂我担任组长并组织组员共同完成“个人图书管理系统”这个项目,第一次和别人合作,才发现运用工程化的思想来做是如此的有必要。
从这里,我才真正的意识到实施一个软件工程并不是说简单的会编码就能够解决问题的,我们更多的精力不是放在编码上,编码只是一个很小的模块,只占到那么小的一个部分。这个事实在很大程度上颠覆了我以前的思想,在我以前的认识中,似乎整个软件就是编码,除此无它,还好有老师的指导,不然真的会出现老师所说的,撞得头破血流之后才想起来用软件工程的思想来完成这个工作。
刚真正开始工作之前,我们费了很多的时间来完成一些前端工作,如需求分析和可行性分析,这块工作在别人看来可能是相对无关紧要,甚至是多于的,其实,换做在以前,我也会这么认为。可是,我现在算是深深地明白了磨刀不误砍柴工的道理,这些工作的完成太有必要了,太重要了,要想你的软件有用有市场,能被别人接受和认可,在进行过程中不会出现崩溃性的问题,这些工作缺一不可。
还有就是接下来的一些设计模块,此模块与软件编码涉及比较紧密,主要是解决一些参数传递和接口通讯的问题,此模块对我的触动远没有上两个模块对我的影响大,因此再次也不做过多的介绍。
在整个活动的完成过程中,作为组长,我收获很多,我发现,要是组里有个人不怎么想做事情时,他对于整个组织的影响是毁灭性的,正所谓“一颗老鼠屎,能坏一仓谷”,以后我的组织里要是出现这样的人,我绝不会给他继续留下来的机会,我会在第一时间将他清除出去。还有就是,作为组长,你要做的最重要的事情,不是发挥自己的聪明才智,而是创造出一个平台,让别人去发挥,你所要做得,出了保证这个平台的完整性和公平性外,还有就是协调好各组员之间的关系。
这就是我的实习感想。
软件工程实习心得体会(二)
时间过的很快,转眼间已经实习将近5个月,其中有2个月是属于完全被流放的。
最先在内部系统组参与内部管理系统开发(struts+mysql+spring+hibernate),之后是去做网络交换机软件的脚本测试。现在又回归内部系统,虽然在脚本组期间,编码能力被别人甩在后头,但至少具有了一些测试经验。
至少自己做的东西,是真正交付到了客户手上,到也稍微有些成就感。
1、浅谈测试
一直以来,我都认为测试是脱离了软件工程范围的工作,不以为屑。但在实际情况中,测试是既重要且难以精湛的.其真正的压力,在于找不到bug,责任在你,而不在于编码人员。一般的测试人员不懂编码,他们靠的是日以累计的经验总结和想象力。而要做到高级测试工程师,则一定要懂编码,因为这是你完全掌握整个系统的方方面面具体运作的前提。但占主导地位的,还是大型系统的集成测试经验。实际项目中,编码时间一般只占30%左右,真正耗费时间的是IT阶段的找 bug与对应bug,此阶段基本评定了coder的编码质量。
2、程序员的困惑
有些人,以为教学视频和代码看多,自己就懂的多,实际做起来,却不知从何下手,问题在那?如何定位?如何解决?通通跟一样能力有关,debug追踪能力,也称调试。在项目组工作不愁源码资源,但问题是蛋糕摆在面前,你如何去消化?
有位同事告诉我:代码看几遍都没用,要去抄,例如一个查询模块,在此基础上去做具体记录的历史记录查询模块,你可能会觉得很简单,但实际情况却往往报一堆异常,配置问题涉及到方方面面,以及数据库字段,传值问题等等,一大堆对于新人来说很郁闷的问题。但不用怕,只要学会调试,一个个问题去追踪,一个个去解决,自然而然,那段“源码”才真正属于你。
3、如何调试追踪
如果你能在短短的时间内就看到问题点在那,放下断点去追踪,出去找工作,绝对没问题。出现问题的时候,不要光看代码,要用实际行动去追踪运行期间的具体值,那是最好途径。eclipse是个很爽的ide,这点做的很好。例如页面内容显示不是自己想要的数据,我们要先从数据库查询语句去下手,设置断点,一步一步step over,让sql字段(存取最终sql语句的字符串)运行到有值,inspect进去看,如果还看不出来,就点击它,copy后在sql客户端去实际运行,看看实际查询出来的表是什么,如果是对的,有可能就是页面调用的错误或者action逻辑的传值问题。
页面错误的调试,基本方法是用右键点击实际网页查看源代码,copy到editplus,就能看到具体错误发生在那几行。通常有几种常见的错误,例如:缺少对象这种很多时候是有些被你调用的字段有可能为空的情况出现的,可以加if(xxx=null)语句加保护。追踪的方法基本就是用alert语句,放在有可能出错的地方。
4、一些习惯
遇到问题先自己思考,无从下手再找高手帮忙看看,注意他帮你看的思路,别在一旁闲着,看多了自己也会了,不然你一辈子都停留在那种水平,从人身上学到的东西远远比书多的多。
解决了一个问题后,要去究根问底去找到问题产生的起因,以防你下次遇到类似的问题再浪费同样的时间。
把代码写的漂亮,注释、空行、规范一样不能少,可读性是放在第一位。曾经看过一个高手写的代码,真的一看就是不同水平的人写的,几乎很完美,读起来很流畅,方便自己也方便别人。
任务完后不要呆着,去要求经理给你更有挑战性的任务,只要你肯去尝试,他们就会对你另言相看,把三天的任务一天加班搞定,效率和忠诚都有了,路也比较好走了。
今天在网上看到《软件实训心得体会三篇》,感觉很有用处,这里给大家转摘到小编,看完如果觉得有用请记得收藏。
小编精心推荐
| | |
是指一种读书、实践后所写的感受性文字。体会是指将学习的东西运用到实践中去。下面是小编带来的软件实训心得体会,欢迎阅读参考。
软件实训心得体会(一)
这次软件工程实训是从xx号开始的,截至xx号。实训内容是用java相关知识(主要是jsp)做物流配送系统。下面谈谈对这次实训的看法。
因为自己平时对java知识储备不足,特别是jsp这一块基本不了解怎么回事,所以一拿到这个,我心里都是没有底的,再加上我被分到的那个组,我知道就意味着是我一个人在战斗了。呵呵,26号,实训开始了,的老师是来自xx国际公司的程序员,一个是xx,一个是xx,都是一身朴素的着装,让我感觉做软件的也没什么两样。老师介绍了自己之后,就直接切入正题了,分析了下我们各个组的系统,即将用到的知识,然后就总体把觉得需要补充的知识(jsp和数据库连接等这几块)给我们实际操作了下,因为当时看到用jsp,还讲的那么认真,当时我就后悔了,平时要是多听点,现在老师这么认真的给我们讲,这是一个多么难得的机会啊。后悔也没用啊,开始还勉强能理解一点,提供最新和免费范文模板参考 后来就直接晕了。然后再给大家介绍了一些即将用到的工具,比如rationalRose,SVN,MyEclipse等等。接下来的几天就不再细讲了。下面谈谈通过这次实训的心得体会吧。
通过这次实训,让我了解到工程开发的过程,可行性分析——需求分析——概要——详细设计——代码编写——测试——验收。从技术方面上,我开始jsp基础基本上零的,在老师和syz2(另外一个物流小组,我一个人基本上是跟她们做的,或者说是看着她们做的)的帮助下,对jsp有了一个大概的认识。其实实训开始前,我还以为做个系统没什么大不了,可是当真正拿到一个项目,我却真的无从下手了,而且就是在知道需求分析和详细设计,在代码编写时,一样寸步难行。通过这个实训,也让我了解到,团队协作是多么的重要。一个人的精力是多么的有限。进一步理解到,企业如此重视团队协作。同时借用老师的话就是团队协作固然重要,但是是建立在个人素质的基础上,假设你个人素质不行,将会影响到整个团队,就别提对团队作更多贡献了。**老师说这几句话的时候,朝向了我,估计是有特殊意义的吧,所以,我将谨记老师的教导。
还有一个收获是从一个同学那里得到的,他的那组成员跟我的这组大体一样,我倒是觉得没什么了,不过他倒是很重视这个问题吧。然后他说出来,我也觉得这个问题确实其实是个大的问题。就是不管你会不会这门技术,小编 会不会做这个东西,态度要正确才好,就算你不会做,你也应该认真的对待,将来出身到社会,就不是说像你现在,不会做就不做,跑去玩了。小胖说出了这段话,也在我身上有了一个印证,虽然我jsp技术知识为0,但我也还是在认真的跟着他们一起做,不会做,就多问,毕竟现在我们是学生,可以毫不顾忌的询问各种问题,老师也会尽力为你回答。将来出身社会就不一样了。虽然,我就算个打酱油的水平,但是这个酱油也要打得有涵量啊。不管怎么样,我能对自己有个交待,虽然我不会,但是这次实训我确实是认真对待了,六天的实训,除了晚上加班外,还花了2个通宵来完成不同阶段的任务,完成与否也不重要了,我至少我做了,这点,是这次我应该对自己的一个肯定。
这次实训的心得基本上就是这些了,最后特别感软国际带我们的那两个老师(周褀,朱映),这两个老师对待我们很平易近人,对我们提出的问题,总是不光解决了,还进行了扩展,晚上也跟我们一起加班加到很晚,印象尤其深刻就是朱映老师为了给小胖解决一个问题,脸都变红了,还在继续努力,这点我并不会觉得老师知识储备不够,我想应该是这个问题的突发吧,一时没想到怎么处理。相反让我感觉更多的就是老师很认真,很负责。还要感谢就是syz2小组的倾力支持,辅导。
软件实训心得体会(二)
通过实训中心老师的课堂讲解与企业化标准的培训各种日常写作指导,教您怎样写范文 ,使我加深了对自己专业的认识。从而确定自己以后的努力方向。要想在短暂的实训时间内,尽可能多的学到东西,就需要我们跟老师或同学进行很好的沟通,加深彼此的了解。只有我们跟老师多沟通,让老师更了解我们,才能跟真切的对我们进行培训工作。由此,班级的文化“共享”就在生活中慢慢形成了。
“纸上得来终觉浅,绝知此事要躬行!”在这短短的时间里,让我深深的感觉到自己在实际应用中所学专业知识的匮乏。让我真真领悟到“学无止境”这句话的涵义。而老师在专业认识周中所讲的,都是课本上没有而对我们又非常实用的东西,这又给我们的实训增加了浓墨淡采的光辉。我懂得了实际生活中,专业知识是怎样应用与实践的。在这些过程中,我不仅知道了职业生涯所需具备的专业知识,而且让我深深体会到一个团队中各成员合作的重要性,要善于团队合作,善于利用别人的智慧,这才是大智慧。靠单一的力量是很难完成一个大项目的,在进行团队合作的时候,还要耐心听取每个成员的意见,使我们的组合达到更加完美。
这次实训带给我太多的感触,它让我知道工作上的辛苦,事业途中的艰辛。让我知道了实际的工作并不像在学校学习那样轻松。
人非生而知之,范文写作 虽然我现在的知识结构还很差,但是我知道要学的知识,一靠努力学习,二靠潜心实践。没有实践,学习就是无源之水,无木。这次实训让我在一瞬间长大:我们不可能永远呆在象牙塔中,过着一种无忧无虑的生活,我们总是要走上社会的,而社会,就是要靠我们这些年轻的一代来推动。这就是我们不远千里来实训的心得和感受,而不久后的我,面临是就业压力,还是继续深造,我想我都应该好好经营自己的时间,充实、完善自我,不要让自己的人生留下任何空白!
实训中除了学到不少专业知识,也了解一些社会的现实性,包括人际交往,沟通方式及相关礼节方面的内容,对于团队开发来说,团结一致使我深有体会。团队的合作注重沟通和信任,不能不屑于做小事,永远都要保持亲和诚信,把专业理论运用到具体实践中,不仅加深我对理论的掌握和运用,还让我拥有了一次又一次难忘的开发经理,这是也是实训最大的收获。
现在我对“一个人最大的财富是他的人生经历和关系网络”这句话非常的有感情,因为它确实帮了我们不少。除此课本上的知识毕竟有限。通过实训,我班同学都有这样一个感觉,写作网,教您怎样写范文 课本上的理论知识与实际工作有很大差距,只有知识是远远不够的,专业技能急需提高。
从最初的笨手笨脚,到现在可以熟练的按照流程开发软件,这都与我班每个人的努力是分不开的。十个月的实训,教会了我们很多东西,同时也锻炼了大家踏实、稳重的能力,每个人都很珍惜这来之不易的实训机会。
在实际工作中经常会和不同的人打交道,然而他们的态度是不可恭维的,你会感觉到他的不耐烦以及他的高傲,所以这就需要学会沟通的方式及,学会灵活面对。通过这十个月的实训,我班同学都收获颇丰,总体来说对这次实训还是很满意的。尽管实训很累,每天早出晚归。但真的很感谢学校能够提供我们这样好的实训机会,以及东软给予我们的实训平台。我们深刻的了解到,只有经历过,才知道其中的滋味。对于我而言,喜欢体验生活,可以说通过这次实训,真真切切的让我了解了什么是软件开发,什么是软件工程,让我对于软件最初的观点也有了本质性的改变!程序员不仅仅是一份职业,更是一份细心+一份耐心+一份责任心=人生价值的诠释。即将走向工作岗位的我们更要不断加强自己的专业技能,社会不会要一个一无是处的人,所以我们要更多更快的从一个学校人向社会人转变。为此我们将会在以后的日子里继续努力,不断激励经验,不断磨砺自己,早日走向工作岗位。
软件实训心得体会(三)
这学期学习了软件工程实践这门课,我觉得这是对上学期的软件工程课程学习的检验,上学期学习软件工程只是我们浅显的认识,相比之下,这学期就更加全面的说明了开发一个项目所需要的步骤以及开发项目过程中所需要注意的诸多细节。最全面的写作网站 如果说上学期的课程注重理论基础的话,那么这学期的软工实践,顾名思义,就是侧重我们动手操作的能力。
原来我认为开发一个项目最重要的就是写代码,似乎整个软件都是编代码,因为自己动手能力不强所以就很排斥做项目。可是经过我们学习软工课程到团队做项目再到学习软件工程实践课程之后,我才真正意识到实施一个软件工程项目并不是说简单的会编码就能够解决问题的,因为一个软件的生命周期分为三个时期:软件定义时期、开发时期、维护时期,而这三个时期整体又分为七个阶段,他们分别是:问题定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试,由此可看出,当我们开发一个项目时,更多的精力不是放在编码上,编码只是一个很小的模块,而是项目的整体结构上。
在写软工实践体会之前,我想在这里一下上学期三人团队做项目的相关事宜。上学期我们三人团队根据软件开发的步骤开发一个名为“西大老乡‘荟’”的社交系统,主要是为西大学子提供一个找老乡的平台。虽然只进行到详细设计阶段,没有进一步实现,但是我还是从中学到很多东西的。首先要先确定项目主题,也就是这个项目用来做什么,可以解决什么问题。接着就是这个项目是否有研究的必要以及是否有解决的办法,针对我们的项目,我们对西大的一些学生做了问卷调查,并从调查中继续完善系统本身的做用户。第三步根据我们确定的项目主题进行需求分析,这一步骤当时做的不是很好,比如所画E-R图、数据流图等都有考虑不周的问题,导致接下来的概要设计、详细设计进行的很困难,有些步骤甚至还需要返工。
从我们在需求分析中出现的问题,使我们明白了软件定义阶段对于一个项目的开发是至关重要的,当软件定义阶段完成时必须要用正式的文档准确的地记录目标系统的需求。只有前期的准备工作做得好,后面的工作才能顺利进行。虽然项目最后没有完全实现,但是起码我们已经初步体会到软件项目开发的步骤,以及每一步所需要完成的文档等内容。
这学期的软件工程实践虽然不是亲自动手开发一个系统,但是张元平老师以“物联网物流仓储管理系统”为主给我们讲解了一个真实系统的开发过程,从计划到项目系统的发布实施,以及每一步必须生成的文档。我主要从以下五个方面谈一下我的心得体会。
第一、行业背景说明方面
对于一个软件系统的开发,第一步就是问题定义,了解所开发系统的行业背景,制定计划。当我们计划确定以后就要对项目系统本身进行可行性研究,主要从技术可行性、经济可行性和操作可行性三个方面着手。就比如《物联网物流仓库管理系统》的行业背景说明文档常详细地分析了当下物联网物流行业的整体业务说明、应用背景、未来发展趋势以及相关应用案例等四个方面,项目团队中系统分析员就可以根据这份文档以及相关的调查资料对将要开发系统的进行定义等工作。
原来我们写这类文档的时候就是草草了事,不会做得这么详细,而这次看到大型项目的行业背景说明也是这么详细,也让自己认识到不管是软件开发的那个阶段都要认真对待,这些琐碎的文档都是后期开发项目的支撑,只要它们做的透彻,后面的开发工作才能更顺利的进行。
第二、项目需求说明方面
这部分项目需求说明就是软件定义时期中需求分析阶段,而该阶段的主要目的就是了解用户的需要,根据用户的需要确定系统必须完成那些工作,并对目标系统提出完整、准确、清晰、具体的要求。在需求分析结束之前系统分析人员要写出一份需求规格说明,即为《物联网物流仓储管理系统》项目需求说明文档。我们可以看出该文档也是非常详细,相比之下我们之前做项目时写的需求规格说明书就非常不合格,不仅格式不正确内容也是少之又少。
在这方面,这篇文档给我启发很大。首先就是文档的格式,要美观整齐,让人看着舒服方便。其次就是文档的内容,原来它不是很重要,写文档的时候也不知道怎么写就借鉴下网上的内容,结果根本就没有把自己项目的需求写明白,以至于自己最后都有些糊涂,所以根据以前的经验教训我会对这部分更加重视。
第三、系统概要设计方面
这部分内容分说的是软件设计时期的概要设计阶段,该阶段的主要目的就是实现系统的功能、设计软件的结构、模块组成以及模块之间的关系。在概要设计阶段,我们可以站在全局的高度上,花较少的成本,从抽象的层次上分析对比多种可能的系统实现方案和软件结构,从中选出最佳方案和最合理的结构。在这个阶段还会具体画出E-R图、数据流图等方面的设计。
比如《物联网物流仓库管理系统》的系统概要设计从项目概述、设计约束、功能单元与功能模块设计、数据E-R图设计、总体设计、界面设计等六个方面介绍,通过读这个文档,我觉得最重要的还是总体设计,分别从逻辑架构设计、物理架构设计、技术架构设计设计系统。在这个阶段中模块要做到高内聚低耦合,这样开发出来的系统才会具有更高的独立性。
在原来做项目时没有编写过这类文档,在该阶段只是画了结构图、层次图以及相关的模块划分,对该类文档尚未重视。通过张老师的讲解和自己的学习,我相信在以后做项目的时候一定会注意到这类文档的编写。
第四、详细设计与分析方面
详细设计阶段就是把概要设计阶段的每个模块进一步设计,确定每个模块所需要的算法和数据结构。在这个阶段还是需要我们设计出程序的详细规格说明,而不是编写程序。在详细设计阶段,系统设计人员可以通过使用程序流程图、盒图、pAD图等过程设计的工具和Jackson图等面向数据结构的设计工具进一步设计系统相关接口,主要包括界面设计接口、业务单设计接口、单元模块设计接口等,这些对于以后的编码工作都是极其重要的。
第五、编码和测试方案方面
关于编码,我认为编码要想做的完美必备条件就是前面的软件定义和软件设计时期要按部就班的做,文档一定要按要求书写,不能偷懒也不能草草书写。对于编码也要有相应的文档书写规范,要使源程序代码的逻辑简明清晰、易读易懂。这样尽管我们不是设计系统的人员,当看到源程序代码的时候也能容易读懂代码的意思。
其次就是测试的内容,从测试的文档中我们可以得出,其实测试在软件开发中同样占据了重要的地位,它主要就是尽可能多的找到问题并排除其中的潜藏的错误,最终把一个高质量的软件系统交给用户使用。它要求测试人员也要有很高的技术水平。
广联达软件是一家上市软件公司,立足建设工程领域,围绕工程项目的全生命周期。今天小编整理了广联达软件实训的感想和心得体会,希望对大家有帮助。
广联达软件实训心得体会篇一
广联达软件确实给我们的工作带来了很多便利,但如何用好软件还是有许多注意事项,否则一个不注意可能就会对你的算量工作带来很多不必要的麻烦。安县项目是我做的第一个完整的广联达模型,首先要感谢我可爱的同事们,在做这个项目过程中给了我很多帮助,从你们身上我学到了很多。在这个过程中我对于广联达软件也建立了一些自己的认识,下面就来疏理一下我总结的一点小经验:
1、是新建项目,都是从钢筋工程开始,一开始就要选择好计算规则,这是之后不能修改的,软件也会自动题示你。
2、在比重设置中修改6#钢筋比重为6.5#的。因为目前市场上没有直径6的钢筋,施工时都是用直径6.5的钢筋替代直径6的钢筋。
3、在2009四川定额工程量计算规则中钢筋(钢丝束、钢绞线)按设计图示长度乘以单位理论质量计算,项目中已综合考虑钢筋、铁件的制作损耗及钢筋的施工搭接用量。所以要在楼层设置中把搭接全部设置为0,这样就不会计算搭接区的量;还有种方法是将把定尺长度全部设置为软件允许的最大值50000mm,接头形式可以定为其他形式。这样只要图式长度在50000mm范围内就不计算搭接,超过50000mm它计算的接头也是其他形式,这样较易分辩。另外在11G101-1第54页右下角注中梁、柱类构件搭接区箍筋直径不小于d/4(d为搭接钢筋最大直径),间距不应大于100mm及5d(d为搭接钢筋最小直径)。而四川定额工程量计算规则中只是说综合考虑钢筋的施工搭接用量,并没有明确说明是否包含了这部分搭接区箍筋加密的量。
4、楼层设置时有架空层和错层要尽量考虑以后工程量的划分和画图方便,我在画第一幢楼时设置楼层过细,把架空层也单独设置一层,结果最后把同层的墙、柱分成了几段,虽然对实体工程量没有影响,但画图布装饰和最后统计工程量的时候就会很麻烦。楼层设置对超高模板的量也有会影响,因为软件计算超高模板时是以层底标高开始计算的,如下图将层底标高设置为-4.5,这时三个区域的板和梁计算超高模板量都是以-4.5为底标高计算的,这要怎么在软件上处理,我还没找到办法,只能最后查看计算式,直接调整工程量。
5、在导入cAD之前要将cAD图纸转换成天正的t3格式,这样可以最大限度的保证导入图形的完整性。在识别板钢筋时,识别完成后会弹出一个如下图的提示框,一定要按照其提示一条一条的修改之后才可以关闭提示框,否则之后再调整板筋布置范围重叠就找不出这个提示框了。
6、在画变截面筏板时最好先统一画成一块整板,用分割功能进行分割,再修改其属性,这样可以保证筏板之间没有空隙,不然在设置筏板变截面时容易出错。
7、在布置剪力墙时要将暗柱覆盖,保证与砌体墙之间没有间隙,不然导入土建算量后房间没有封闭,软件不能自动识别,布置装饰将会很麻烦。
8、总说明中的梁构造腰筋及次梁加筋可以在所有梁布置完成后统一布置。如梁构造腰筋是以梁腹板高度为设置依据时,一定要在板布置完成后才布置,因为计算梁腹板高度是要扣除板厚的。
9、自动生成砌体加筋时,一定要点开加筋形式查看一下相应的图形类型,按实际情况调整一下选择参数化图形。这样才能准确统计出相应的预埋件和植筋数量。
10、布置墙面时,如一匹墙要分成两种墙面,那么使用打断功能将其打断,不要删除别一段,可以直接修改属性,如果将其删除,之后再画别一段墙面时,就不容易布置上去了。
软件不是万能的,最后还是会留下一些零星工程需要我们自已手算,如屋面爬梯、窗台栏杆、排烟道、预埋铁件等等,在我们辛辛苦苦终于建完模型之后一定不要忘了它们。
广联达软件实训心得体会篇二
我非常感谢公司给我们员工的集体培训,也很荣幸参加了这次培训,这说明公司对我们员工培训的重视,反映了公司重视人才,培养人才的战略方针;对于在公司技术系统的我,也非常珍惜这次机会。
本次钢筋翻样培训,我觉得意义挺大的,虽然和以往的培训相比累不少,但是苦中有甜。
经过这几天的培训,完全打破了我没培训之前认为钢筋翻样这是个很枯燥乏味的过程的那种想法,我认为最主要的是,它是一个具有挑战性、充满艺术性的工作。虽然规范都一样,但是每个人的思考方式不一样,所以导致了翻样结果不相同,但都是正确的结果。这就是艺术性的所在。我们应该本着追求工程速率同时为公司创造更多价值的思想去端正工作态度。
在本次6天的培训中我收获了不少;首先我了解到之前被忽视的技术细节,比如在考虑钢筋搭接的时候我就常常忽视。其次是现场施工与一般翻样的差距,这个我觉得主要表现在断料的时候,一方面我们要考虑原料,另外我们还要重视现场,把理论和实际紧密联系在一起;最后我也认识到了自己的不足,尤其在细心这一块还如要重视和培养。培训的老师都很有责任心和耐心,基本上覆盖了大部分知识点。上课的过程也是互动的,生动有趣,把每组按项目分到7个人,不懂
得还可以相互讨论;同时每天下午课前都会组织大家进行互动式游戏,既丰富了培训生活,也活跃了课堂气氛。
虽然此次培训内容很丰富,涉及知识也很广,前面两天主要是规范翻样,后面两天课程是现场精细化管理,虽然都是翻样,但是差别还是有不少,老师讲解完后,我自己领悟到了两者的差别,不过考核的时候我发现不少同学把两者弄混淆了。所以我觉得这次培训还可以添加一节课讲解实际翻样和按规范翻样的差别。相信这样的课程会让我们更清醒的认识到翻样的艺术性和责任的重大。
平时在现场我看到一些拉筋和箍筋在楼层清理的时候也并一起清理了,可能是劳务队在施工的时候没有节省材料,导致的浪费。这个就表现在我们对钢筋的监管不够。我们平时翻样也要把这些纳入到回收清单里面。尽量节省材料。
本次培训的形式主要是以ppt讲义的方式,我觉得培训的形式可以再丰富一点,这样可以更加增强培训的趣味性和员工培训的积极性。此外此次培训可能受培训时间的限制,课程安排的过紧。很多同学反映比较疲劳,有时候晚上还要进行闭卷考试。
最后,学习能让人进步,工作能让人自信,相信我们在不断地学习和工作经验积累当中能让自己变得更加完善,也感谢组织这次培训的公司,和参与培训的老师们。
下页更多广联达软件实训心得体会
广联达软件实训心得体会篇三
本学期我们重点学习了广联达图形算量软件和钢筋抽样软件。通过对广联达软件的培训学习,不仅提高了我的识图能力,还提升了我对有关工程软件操作的热爱。
在学习广联达软件之前,我们重点学习了AutocAD制图软件,并简单地学习了解了pKpm计价软件。通过对三种软件的学习和比较,我觉得在绘图速度方面,广联达图形算量软件和pKpm计价软件更为优秀。因为这两种软件可以直接建立轴网,在画门窗时也不需要创建块慢慢插入,只要定义好构件直接画就好了。但是,两种软件毕竟不是专门的制图软件,对比AutocAD制图软件来说,它们在绘图上做不到足够的精确细致。
广联达图形算量软件GcL8.0操作起来比较简单,基本上只要按照图纸设定好各个构件的信息属性就行。但是,在操作过程中若不小心弄错层就不好处理了了,而这一点是它不如GcL2008之处。很遗憾,因为没有对GcL2008软件的集中学习,对于它在处理错层方面还是不大了解。
在我看来,广联达软件中的三维显示功能是非常实用的。三维显示使我们所绘制的图形立体画,能从不同的角度观察图形从而清晰地了解建筑物的一部分构造,这对提高我们的空间想象能力是大有帮助的。而识图最大的障碍就是空间想象能力不佳。
画图过程中,我觉得在设置工程信息方面有必要认真、严谨。一定要把各个信息(如基础形式、檐高、结构标高等)确定好,以免影响后续的作业。对于主体结构,应该注意是否需要偏移。确定好了,再做梁、柱、钢筋等工程时才不会出现算量错误。
我觉得广联达的钢筋抽样软件是广联达公司最有特色的软件。它最大限度开放了各类钢筋的计算方法并能自动考虑构件之间的关联和扣减,因此我们只需完成绘图即可实现钢筋量计算。
在钢筋编辑中设置的计算规则可以修改,而计算结果能直观显示每根钢筋的形状、计算过程、搭接形式、计算公式,这样便于查看和控制钢筋绘制以便满足多种算量需求。
在软件学习中,资源共享应该是个比较值得提倡的问题。广联达钢筋抽样软件与图形算量软件GcL8.0实现统一平台,并且不用安装cAD就能直接将cAD图导入,很好地节省了算量时间。
在使用软件过程中,我觉得应该注意的问题:
在工程设置时,结构类型、设防烈度、檐高、抗震等级的输入不正确,会影响计算结果。绘制板时,单边标注板负筋长度不含支座宽时,即使在计算设置里设了单边标注负筋长度到支座内边线,除负筋在墙处能计算正确外(墙不是板的支座),在有梁(梁为板支座)处的板负筋,软件在计算时会扣除1/2支座宽,计算有误。为避免此类问题发生,需在有墙的地方布置。单边标注板负筋时应选择按墙布置,同理有梁时选按梁布置,在有连梁的地方选按板边布置或画线布置。
在绘制柱时,框架柱在画完构件后,顶层柱应自动判断边角柱,顶层柱不可在全部纵筋处输入钢筋信息,应分别在角筋、H一边纵筋、B一边纵筋处分别输入,否则,即使边角柱判断成功,软件也不会正确计算。
感谢老师带领我们学习各种工程软件,让我们熟悉操作流程,为我们以后的就业创造更有利的竞争条件。虽然各种软件能为我们以后的工程制图、算量、计价提高效率,但我觉得对软件我们不能过分的依赖,不要希望它能解决所有的问题,算出所有的量,我们一定要运用自己的智慧,把软件的很多功能结合起来,找出最快最好的方法和技巧。真正的要软件为我们所用,而不是软件来主导我们!
广联达软件实训心得体会篇四
在没有上软件课之前就听说了广联达软件,它包括图形算量软件、钢筋抽样软件、计价软件。广联达软件在造价方面的应用很广泛,方便、快捷就是它之所以广为人知的秘诀。从大四的上学期我们开始接触广联达软件,但是课时太少,不能全面、系统、详细地了解广联达是一个遗憾,希望在以后的学习工作中加强练习,做到熟练掌握。下面就说一些我的学习心得:
一、图形算量软件强化识图能力
开始上课后,第一个接触的就是图形算量软件,要求我们把图纸上除钢筋外的所有信息都输入这个软件,就连一个构件的尺寸都不能出错,否则就会造成以后算价的错误。如一个单体工程,它的墙类型也许会有很多种,除了有内、外墙之分外,同是外墙,材质可能不同,尺寸也可能不一样;柱子就更加麻烦,若是矩形柱还好说,当柱子是异形柱的时候,我们需要加倍小心,对照图纸输入参数化信息。这就要求我们仔细读图,认真核查图纸信息;逐项输入构件信息,做到不漏不错。
在大二的时候我对读图掌握的不是很好,所以刚开始学习图形算量时有点困难,通过图形算量的学习,使我的读图能力有了很大的提高。同时,也强化了我的cAD使用能力,因为,广联达有些画图的地方和cAD是互通的。
二、钢筋抽样软件熟悉钢筋结构
在没学钢筋抽样软件之前,对它抱有很大的恐惧心理,因为我们在概预算的课程中没有学习抽筋,对它我们是完全陌生的,人在接触新事物时总是会害怕的,害怕学不好。因为害怕,也因为好奇,所以在学钢筋抽样时就更加用心。经过一段时间的学习后,才发现钢筋抽样其实也不是太难,只要能看懂配筋图,仔细输入配筋信息,钢筋的绘制就是一项简单的工作了。绘制钢筋最重要的就是要细心,不能漏筋,也不能错筋,不然会直接影响钢筋用量,导致最后的汇总计价的不正确。
三、计价软件学会汇总计价
在图形算量和钢筋抽样结束之后,就要进行汇总计价了,汇总计算的结果就是预算的依据。计价软件是给工程量套定额出价钱用的,计价时只需要把以前做好的工程导入计价软件,然后对照市场价格表,它就会在很短的时间里得出每个分项工程的价钱。利用计价软件汇总计算不仅可以节约大量的人力,更可以省下很多的时间。在这个时间就是金钱的社会,尤其是在工期直接关系到工程款的建筑行业,节省了时间就等于赢在了起点上。
软件课在匆匆忙忙中结束了,不能说我们可以完全掌握广联达的使用,起码我们入了门,为以后的继续学习打下了基础。虽然造价软件不是只有广联达,但是,通过学习这一个,我们掌握了一种学习态度细心、耐心,相信这对其他软件的学习也是有帮助的!
经过这学期软件工程实验的学习,深深感到用户需求对软件的重要性。成功的软件产品是建立在成功的需求基础之上的,而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决,而开发人员开始帮助用户解决这个问题,沟通就开始了。
需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识:用户知道需求是什么,我们所要做的就是和他们交谈从他们那里得到需求,只要问用户系统的目标特征,什么是要完成的,什么样的系统能适合商业需要就可以了,但是实际上需求获取并不是想象的这样简单,这条沟通之路布满了荆棘。首先需求获取要定义问题范围,系统的边界往往是很难明确的,用户不了解技术实现的细节,这样造成了系统目标的混淆。
其次是对问题的理解,用户对计算机系统的能力和限制缺乏了解,任何一个系统都会有很多的用户或者不同类型的用户,每个用户只知道自己需要的系统,而不知道系统的整体情况,他们不知道系统作为一个整体怎么样工作效率更好,也不太清楚那些工作可以交给软件完成,他们不清楚需求是什么,或者说如何以一种精确的方式来描述需求,他们需要开发人员的协助和指导,但是用户与开发人员之间的交流很容易出现障碍,忽略了那些被认为是"很明显"的信息。最后是需求的确认,因为需求的不稳定性往往随着时间的推移产生变动,使之难以确认。为了克服以上的问题,必须有组织的执行需求的获取活动。
需求获取活动要完成的任务或者步骤的过程如下:
1、编写项目视图和范围文档
系统的需求包括四个不同的层次:业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务,这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。
非功能性需求是用户对系统良好运作提出的期望,包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户需求,然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求,应该包括高层的产品业务目标,评估问题解决方案的商业和技术可行性,所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上。
2、用户群分类
系统用户在很多方面存在着差异,例如:使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素质和喜好等等。根据这些差异,你可以把这些不同的用户分成不同的用户类。与ulm中usecase的actor概念一样,用户类不一定都指人,也可以包括其他应用系统、接口或者硬件,这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点,并详细描述出它们的个性特点及任务状况,将有助于需求的获取和系统设计。
3、建立核心队
通常用户和开发人员不自觉的都有一种"我们和他们"的想法,产生一种对立关系,把彼此放在对立面,每一方都定义自己的"边界",只想自己的利益而忽略对方的想法。他们通过文档、记录和对话来沟通,而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的,不会给双方带来一点益处,良好的沟通关系没有建立导致了误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么,同时也知道要成功对方需要什么时,才能建立起一种合作关系。
为了建立合作关系通常采取一种组队的方式来获取需求,建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧,小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流,但交流时应注意以下原则:小组会议应该由中立方来组织和主持,用户和开发人员都要参加;交流预先要确定准备和参与的规则;议题要明确并覆盖所有关键点,但信息来源应该自由;交流目标要明确,并告知所有的成员。
4、确定使用实例
从用户代表处收集他们将使用系统完成所需任务的描述,讨论用户与系统间的交互方式和对话要求,这就是使用实例,一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。使用实例方法给需求获取带来的好处来自于该方法是用以任务为中心和以用户为中心的观点,比起使用以功能为中心和以开发者为中心的方法,使用实例方法可以使用户更清楚地理解和认识到新系统允许他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述,尽量使用主动语态,用"系统"或者"用户"作为主语,比如"用户提交用户密码,系统验证用户密码是否正确",还有一点在描述中不要设计界面细节,比如"用户从下拉框中选择产品类型"。使用实例为以后写用例场景描述中的基本路径和扩展路径提供了素材。
5、分析用户工作流程
分析用户工作流程观察用户执行业务任务的过程,通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求,统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括:编号,为每个用例分配一个唯一的编号,为需求的追溯提供了方便;参与者,与这个用例交互的 actor;前置条件,开始用例前所必须具备的系统状态;后置条件,用例完成后系统达到的状态;基本路径,用例完成的关键路径,也是用户期望的路径;扩展点,基本路径的分枝,表示意外情况;字段说明,路径中名称的进一步分解说明,对以后类属性的定义和数据库字段设计起作用;设计约束,实现用例的非功能约束。
6、检查问题报告
通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法,负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
7、需求重用
如果客户要求的功能与已有的系统很相似,则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法,像分析模式和设计模式一样,需求也有自己的模式。
总结 :经过一学期的软工实验,深刻感到其重要性的同时也学到了不少的东西 ,将对我在今后的软件开发过程中起极大的作用。
展开全文
相关推荐范文