明确好心得的主题之后我们写的时候才会更加顺畅,心得的积累需要一个长期的过程,职场好文网小编今天就为您带来了软件工程心得体会6篇,相信一定会对你有所帮助。
软件工程心得体会篇1
这次软件工程实训是从20__.12.26号开始的,截至20__.12.31号。实训内容是用java相关知识(主要是jsp)做一个物流配送系统。下面谈谈对这次实训的看法。
因为自己平时对java知识储备不足,特别是jsp这一块基本不了解怎么回事,所以一拿到这个项目,我心里都是没有底的,再加上我被分到的那个组,我知道就意味着是我一个人在战斗了。呵呵,26号,实训开始了,我们的老师是来自中软国际公司的程序员,一个是周褀,一个是朱映,都是一身朴素的着装,让我感觉做软件的也没什么两样。老师介绍了自己之后,就直接切入正题了,分析了下我们各个组的系统,即将用到的知识,然后就总体把觉得需要补充的知识(jsp和数据库连接等这几块)给我们实际操作了下,因为当时看到用jsp,还讲的那么认真,当时我就后悔了,平时要是多听点,现在老师这么认真的给我们讲,这是一个多么难得的机会啊。后悔也没用啊,开始还勉强能理解一点,后来就直接晕了。然后再给大家介绍了一些即将用到的工具,比如rationalrose,svn,myeclipse等等。接下来的几天就不再细讲了。下面谈谈通过这次实训的心得体会吧。
通过这次实训,让我了解到工程开发的过程,可行性分析——>需求分析——>概要设计——>详细设计——>代码编写——>测试——>验收。从技术方面上,我开始jsp基础基本上就是零的,在老师和syz2(另外一个物流小组,我一个人基本上是跟她们做的,或者说是看着她们做的)的帮助下,对jsp有了一个大概的认识。其实实训开始前,我还以为做个系统没什么大不了,可是当真正拿到一个项目,我却真的无从下手了,而且就是在知道需求分析和详细设计,在代码编写时,一样寸步难行。通过这个实训,也让我了解到,团队协作是多么的重要。一个人的精力是多么的有限。进一步理解到,企业为什么如此重视团队协作。同时借用老师的话就是团队协作固然重要,但是是建立在个人素质的基础上,假设你个人素质不行,将会影响到整个团队,就别提对团队作更多贡献了。__老师说这几句话的时候,朝向了我,估计是有特殊意义的吧,所以,我将谨记老师的教导。
还有一个收获是从一个同学(小胖)那里得到的,他的那组成员跟我的这组大体一样,我倒是觉得没什么了,不过他倒是很重视这个问题吧。然后他说出来,我也觉得这个问题确实其实是个大的问题。就是不管你会不会这门技术,会不会做这个东西,态度要正确才好,就算你不会做,你也应该认真的对待,将来 出身到社会,就不是说像你现在,不会做就不做,跑去玩游戏了。小胖说出了这段话,也在我身上有了一个印证,虽然我jsp技术知识为0,但我也还是在认真的跟着他们一起做,不会做,就多问,毕竟现在我们是学生,可以毫不顾忌的询问各种问题,老师也会尽力为你回答。将来出身社会就不一样了。虽然,我就算个打酱油的水平,但是这个酱油也要打得有涵量啊。不管怎么样,我能对自己有个交待,虽然我不会,但是这次实训我确实是认真对待了,六天的实训,除了晚上加班外,还花了2个通宵来完成不同阶段的任务,完成与否也不重要了,我至少我做了,这点,是这次我应该对自己的一个肯定。
这次实训的心得基本上就是这些了,最后特别感谢中软国际带我们的那两个老师(周褀,朱映),这两个老师对待我们很平易近人,对我们提出的问题,总是不光解决了,还进行了扩展,晚上也跟我们一起加班加到很晚,印象尤其深刻就是朱映老师为了给小胖解决一个问题,脸都变红了,还在继续努力,这点我并不会觉得老师知识储备不够,我想应该是这个问题的突发吧,一时没想到怎么处理。相反让我感觉更多的就是老师很认真,很负责。还要感谢就是syz2小组的倾力支持,辅导。
软件工程心得体会篇2
曾经看过一本书叫《道法自然》,内容略记得一二,但我最欣赏的是它的书名。软件设计没什么太神秘有东西,只要用心体会,其实一切都很自然。软件的设计之“道”,也不在于设计有多么的华丽、精巧,而在于其朴实、自然,最终达到“以无招胜有招”,进入一个全新的境界。
一、软件设计理论的层次
以我的拙见,软件设计领域中的各种概念,可以分为以下几个层次来进行理解:
1、软件设计的目的:重用性、扩展性。
这是最高的层次,是应对软件危机的需要。
2、设计原则:低耦合、高聚合。
各种软件设计的原则,如依赖倒置原则、单一职则原则、面向接口等,以及各种设计模式,其根本的目的其实只是为了降低耦合这么简单。因为只有低耦合才能更好的适应变化,更好的重用和扩展。
3、实现方法:运用设计模式封装变化、降低耦合。
设计模式只是用来“封装变化、降低耦合”的工具而已。它是面向对象设计时代的产物,其本质就是充分运用面向对象的三个特性,即:封装、继承和多态,进行灵活的组合运用。
二、关于耦合
1、耦合的粒度
耦合无论如何也是不可避免的。当我们实现接口、继承父类的时候,就会不可避免的产生耦合。耦合是有不同粒度的,我们解耦到什么粒度为止,我认为应以模块的重用粒度为准。尽量解除重用模块或对象之间的耦合。而重用模块之内的耦合,应属于聚合的范畴,所以不要盲目的去解耦,否则就陷入了误区。
2、解耦的原理
怎样才能解耦呢,或者说为什么各种设计模式能达到解耦的目的呢?我觉得有以下几个思路:
(1)将具体的东西抽象处理
(2)将分散的东西集中处理
而面向对象中的接口、继承正为我们提供了这样的一种机制。通过访问接口或基类或抽象类,而不是具体的实现类,从而与具体的实现类达到了解耦的目的。我们还可以设计一些控制类,像润滑剂一样,协调各实现类之间的访问,也可以达到耦的目的。
事实上,各种设计模式的基本思想也就是这样。创建型模式是为了解除创建对象时产生的耦合,实际上是解除对类称名的依赖,而结构型和行为型是为了解除对象属性或方法的直接调用。不管什么设计模式,都是将对具体实现类的访问提升为对接口、基类或用于协调的控制类的访问。
三、关于接口
这一节更具体,谈一谈接口,因为使用接口是软件设计的重要手段,但已经不属于“道”了~
1、接口与继承
接口描述的是对象某一个方面行为特征。使用接口与使用继承关系各有优缺点,使用子类继承可以继承父类的功能,体现了重用的精神。而接品更加灵活,因为它解除了子类与父类之间的高度耦合,它体现在灵活扩展的精神。
2、接口与纯虚类
理论上接口可以由纯虚基类实现类似的功能,那为什么还我们不去掉接口的概念,而直接使用虚类呢?
接口存在的理由就是它更加灵活,关系简单,易于理解。比如一个类可以实现十几个甚至几十个接口,但一般开发工具只支持单继承(由于多继承太容易导致混乱和冲突),如果要继承十几层,系统结构想必会无法理解了,我以为这是接口存在的最重要的原因。
如果接口和虚类继承结合使用,可以产生强大的威力,这也是许多设计模式的“杀手锏”。
以上算是总结一下自己的心得。肯定有不少片面之处,请各位指教。
软件工程心得体会篇3
转眼之间,两个月的实习期即将结束,回顾这两个月的实习工作,感触很深,收获颇丰。这两个月,在领导和同事们的悉心关怀和指导下,通过我自身的不懈努力,我学到了人生难得的工作经验和社会见识。我将从以下几个方面总结软件工程岗位工作实习这段时间自己体会和心得:
在软件工程岗位工作的实习过程中,我始终把学习作为获得新知识、掌握方法、提高能力、解决问题的一条重要途径和方法,切实做到用理论武装头脑、指导实践、推动工作。思想上积极进取,积极的把自己现有的知识用于社会实践中,在实践中也才能检验知识的有用性。
在这两个月的实习工作中给我最大的感触就是:我们在学校学到了很多的理论知识,但很少用于社会实践中,这样理论和实践就大大的脱节了,以至于在以后的学习和生活中找不到方向,无法学以致用。同时,在工作中不断的学习也是弥补自己的不足的有效方式。信息时代,瞬息万变,社会在变化,人也在变化,所以你一天不学习,你就会落伍。通过这两个月的实习,并结合软件工程岗位工作的实际情况,认真学习的软件工程岗位工作各项政策制度、管理制度和工作条例,使工作中的困难有了最有力地解决武器。通过这些工作条例的学习使我进一步加深了对各项工作的理解,可以求真务实的开展各项工作。
在软件工程岗位工作中我都本着认真负责的态度去对待每项工作。虽然开始由于经验不足和认识不够,觉得在软件工程岗位工作中找不到事情做,不能得到锻炼的`目的,但我迅速从自身出发寻找原因,和同事交流,认识到自己的不足,以至于迅速的转变自己的角色和工作定位。
为使自己尽快熟悉工作,进入角色,我一方面抓紧时间查看相关资料,熟悉自己的工作职责,另一方面我虚心向领导、同事请教使自己对软件工程岗位工作的情况有了一个比较系统、全面的认知和了解。根据软件工程岗位工作的实际情况,结合自身的优势,把握工作的重点和难点,尽心尽力完成软件工程岗位工作的任务。两个月的实习工作,我经常得到了同事的好评和领导的赞许。
从大学校门跨入到软件工程岗位工作岗位,一开始我难以适应角色的转变,不能发现问题,从而解决问题,认为没有多少事情可以做,我就有一点失望,开始的热情有点消退,完全找不到方向。但我还是尽量保持当初的那份热情,想干有用的事的态度,不断的做好一些杂事,同时也勇于协助同事做好各项工作,慢慢的就找到了自己的角色,明白自己该干什么,这就是一个热情的问题,只要我保持极大的热情,相信自己一定会得到认可,没有不会做,没有做不好,只有你愿不愿意做。转变自己的角色,从一位学生到一位工作人员的转变,不仅仅是角色的变化,更是思想观念的转变。
在工作间能得到领导的充分信任,并在按时完成上级分配给我的各项工作的同时,还能积极主动地协助其他同事处理一些内务工作。个人的能力只有融入团队,才能实现最大的价值。实习期的工作,让我充分认识到团队精神的重要性。
团队的精髓是共同进步。没有共同进步,相互合作,团队如同一盘散沙。相互合作,团队就会齐心协力,成为一个强有力的集体。很多人经常把团队和工作团体混为一谈,其实两者之间存在本质上的区别。优秀的工作团体与团队一样,具有能够一起分享信息、观点和创意,共同决策以帮助每个成员能够更好地工作,同时强化个人工作标准的特点。但工作团体主要是把工作目标分解到个人,其本质上是注重个人目标和责任,工作团体目标只是个人目标的简单总和,工作团体的成员不会为超出自己义务范围的结果负责,也不会尝试那种因为多名成员共同工作而带来的增值效应。
几个月来,我虽然努力做了一些工作,但距离领导的要求还有不小差距,如理论水平、工作能力上还有待进一步提高,对软件工程岗位工作岗位还不够熟悉等等,这些问题,我决心实习报告在今后的工作和学习中努力加以改进和解决,使自己更好地做好本职工作。
软件工程心得体会篇4
在这次软件工程课程中,我学到了很多东西,第一次深刻的体会到了什么叫做用工程化的思想来编写软件,以前自己也写过一些小型软件,没有做过大型的项目,直到这次课堂我担任组长并组织组员共同完成“个人图书管理系统”这个项目,第一次和别人合作,才发现运用工程化的思想来做是如此的有必要。
从这里,我才真正的意识到实施一个软件工程并不是说简单的会编码就能够解决问题的,我们更多的精力不是放在编码上,编码只是一个很小的模块,只占到那么小的一个部分。这个事实在很大程度上颠覆了我以前的思想,在我以前的认识中,似乎整个软件就是编码,除此无它,还好有老师的指导,不然真的会出现老师所说的,撞得头破血流之后才想起来用软件工程的思想来完成这个工作。
刚真正开始工作之前,我们费了很多的时间来完成一些前端工作,如需求分析和可行性分析,这块工作在别人看来可能是相对无关紧要,甚至是多于的,其实,换做在以前,我也会这么认为。可是,我现在算是深深地明白了磨刀不误砍柴工的道理,这些工作的完成太有必要了,太重要了,要想你的软件有用有市场,能被别人接受和认可,在进行过程中不会出现崩溃性的问题,这些工作缺一不可。
还有就是接下来的一些设计模块,此模块与软件编码涉及比较紧密,主要是解决一些参数传递和接口通讯的问题,此模块对我的触动远没有上两个模块对我的影响大,因此再次也不做过多的介绍。
在整个活动的完成过程中,作为组长,我收获很多,我发现,要是组里有个人不怎么想做事情时,他对于整个组织的影响是毁灭性的,正所谓“一颗老鼠屎,能坏一仓谷”,以后我的组织里要是出现这样的人,我绝不会给他继续留下来的机会,我会在第一时间将他清除出去。还有就是,作为组长,你要做的最重要的事情,不是发挥自己的聪明才智,而是创造出一个平台,让别人去发挥,你所要做得,出了保证这个平台的完整性和公平性外,还有就是协调好各组员之间的关系。
这就是我的实习感想。
软件工程心得体会篇5
在本学期的软件工程课程的学习中,我们学习了十一章的内容。第一章软件与软件工程的概念,这一章主要讲解的是一些概念性和基础性的内容,例如软件的概念、特性,软件危机的主要表现,软件工程的概念以及软件生存期、典型生存期模型等等。第二章软件工程方法与工具,这一章主要对软件工程方法进行介绍,包括三种方法:传统方法、面向对象方法、形式化方法。还引出了工具uml。第三章软件需求获取与结构化分析方法,本章详细介绍了需求获取与需求分析阶段的任务以及结构化分析方法,画分层的数据流图、e—r图以及状态图式本节的重点。第四章结构化分析方法,这一章重点讲解了使用变换型映射方法和事务型映射方法生成初始的模块结构以及模块结构的改进。第五章编码,这一章重点讲解了编码的风格及规范,还告诉我们编码规范说带来的好处,并告诫我们将来一点要形成好的编码风格。第六章软件测试方法,本章讲解了软件测试相关的概念及重要性,软件测试与开发各个阶段的关系;还介绍了白盒测试技术以及黑河测试技术。第七章统一建模语言uml概述,本章详细介绍了uml的基本模式、事物、关系及建模时用到的各种图进行了介绍。第八章面向对象分析,这一章主要讲解了面向对象分析的3种模型,包括功能模型、静态模型和动态模型。第九章软件体系结构与设计模式,本章对软件体系结构的基本概念、典型风格等进行了讲解。第十章面向对象设计,本章的重点是对面向对象分析时建立的对象模型进行调整和细化。第十一章软件维护,本章主要介绍软件维护的任务、软件维护活动以及软件维护方法进行了介绍。
要学习软件工程,学会如何系统的思考,以及养成良好的编码习惯,想学好软件工程,就必须知道软件工程的目标、过程和原则:软件工程目标:生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题,它们形成了对过程、过程模型及工程方法选取的约束。
软件工程过程:生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程,还有管理过程、支持过程、培训过程等。
软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
我们学习了详细设计的方法,其原则是过程描述是否易于理解、复审和维护,进而过程描述能够自然地转换成代码,并保证详细设计与代码完全一致。包括程序流程图、n—s图、pad图、hipo图
程序流程图:程序流程图又称之为程序框图,它是软件开发者最熟悉的一种算法表达工具。它独立于任何一种程序设计语言,比较直观和清晰地描述过程的控制流程,易于学习掌握。在流程图中只能使用下述的五种基本控制结构:顺序型;选择型;while型循环;until型循环;多情况型选择。
n—s图:一种符合结构化程序设计原则的图形描述工具,称为盒图,又称为n—s图。在n—s图中,为了表示五种基本控制结构,规定了五种图形构件。顺序型;选择型;while重复型;until重复型;多分支选择型。
pad图:它是用结构化程序设计思想表现程序逻辑结构的图形工具。pad也设置了五种基本控制结构的图示,并允许递归使用。
hipo图:hipo图是由一组ipo图加一张hc图组成。它是美国ibm公司在软件设计中使用的主要表达工具。
hc图既是层次图,用于表示软件的分层结构。hc图中的每一个模块,均可用一张ipo图来描述。ipo图由输入、处理和输出三个框组成,需要时还可以增加一个数据文件框,这种图形的优点,是能够直观地显示输入—处理—输出三者之间的联系。
还有测试方法:按照测试过程是否在实际应用环境中来分,有静态分析与动态测试。测试方法有分析方法(包括静态分析法与白盒法)与非分析方法(称黑盒法)。
静态分析技术:不执行被测软件,可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。
动态测试技术:当把程序作为一个函数,输入的全体称为函数的定义域,输出的全体称为函数的值域,函数则描述了输入的定义域与输出值域的关系。
还学习了其他很多工具、语言、方法等,虽然不是都学得很透彻,但我相信在今后的学习中一定会慢慢的完善的。
软件工程对于初学者来说,知识基础较薄弱,对一些应用操作、概念、工具方法等理解起来较为困难,要能从整体概念上较好地理解和把握、学好软件工程,不是仅仅把几本专业书籍细致地看几遍,然后上机练习几次就可以成功,学习过程中要注意多看多练要注意结合实际,更要多思考,面对错误不要一范就问,要尝试自己去解决。但是还要注意什么都学,肯定是什么都学不透的,要集中精力打攻坚战,学习软件工程首先要明白自己的学习目标究竟是什么,根据自己的实际工作出发,有针对性的在相应的学习方向上进行提高,制定出详细的学习规划。还要注意与其他科目的相辅相成,就像我们在学习面向对象分析的时候要结合大一学习的面向对象及其方法学这一专业科目进行研究拓展;在学习语言时,要看看与c语言的联系,多思多想,把从各个科目学到的知识通汇贯通。
在软件工程的学习中,我了解到了软件并非是一些代码这么简单,在开发软件的过程中,编写代码的工作量其实只占不到所有工程量的30%,而后期的管理和维护更是占了60%到80%之多。一个完整的项目规划须包括,软件的定义,可行性分析报告,项目开发计划,软件需求说明书,概要设计说明书,详细设计说明书,用户操作手册,测试计划,测试分析报告,开发进度报告,项目开发总结报告,软件维护手册,软件问题报告,软件修改报告,等多个文档,每个文档都要上级验收审查,而文档数量众多,要做好这点真的不是很容易,而恰恰写好文档正能保证完成软件工程其中一个目的的关键,既研究如何用最小的开销做出生存期较长的软件,再加上各个阶段都要进行周密的策划、详细的分工部署和人员安排,且各阶段要据具体情况不断的反复才能达成,所以代码只是开发软件这个浩大的工程的一个小小的过程。
而编码的学习中,我更了解到形成自己独特的规范的编码风格是非常重要的事。因为这影响到了软件后期繁重的维护,大家都要阅读你的'程序,如果你写的程序毫无规范可言,那么别人怎么能读懂你的程序?读不懂程序,维护又从何谈起呢?所以,我们在今后的学习中,一定要注意这方面的培养,在写程序的过程中,要逐步的在规范的基础上形成属于自己的风格,即方便自己的修改,也方便日后他人的阅读。
在学习中,我们还要注意比较三种方法的优缺点,例如:传统方法虽然使软件摆脱了混乱和无序,但其在适应需求变化的方面不够灵活,而且传统方法要么面向行为,要么面向数据,缺乏两者的有机结合。而面向对象方法的程序设计和问题求解更符合人们日常自然的思维习惯,适合大型、复杂及交互性比较强的系统。形式化方法则是一中基于形式化数学变换的软件开发方法,它可将系统的规格说明转换为可执行的程序。
在今后的学习中要注意多读书、多思考、多练习、多讨论,不断熟悉书本的基础,并以此为基础将其扩散开来,应用于今后的实践。不断锻炼自己,向一名合格的程序设计师迈进。
软件工程心得体会篇6
整本书的内容逻辑很清晰明了,由浅入深循序渐进,首先我就大概描述下我们所学的内容,第一章是从整体分析软件工程这门学科的发展和所处的社会环境,接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于uml面向对象分析建模等。接着我就详细介绍下我对这门课程知识点的理解概括:
软件工程是指导计算机软件开发和维护的工程学科。
软件生存周期:一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。软件的生存周期可分为八个阶段:①问题定义;②可行性研究;③需求分析;④总体(概要)设计;⑤详细设计;⑥编码与单元测试;⑦综合测试;⑧软件维护;瀑布模式:原型进化模式:增量模式:螺旋模式:
软件开发的整个过程:①需要项目团队,组建优秀的团队可以开发出更搞质量的软件产品。任务开发团队要求小而精,成员大多在8人以内,主要成员有项目负责人、开发人员、资料管理员和软件测试员。②项目计划是为了使软件开发各项工作有秩序地进行,包括任务分配和基于里程碑的进度安排,甘特图和任务网络图是用来描述进度计划的工具。项目计划书可以作为软件开发的工作指南。③项目成本估算,由于项目有来自各方面的成本包括工资开支、场地费、差旅费、设备费和资料费等,但是软件主要是对人力成本的估算,常用的方法有程序代码成本估算法等。④软件风险管理包括很多不确定的风险因素,如计划风险、管理风险、需求风险、技术风险、人员风险、产品风险、用户风险和商业风险等等,而风险管理的主要任务是:风险识别、风险评估、和风险防范。⑤软件文档管理,软件文档是工程模式软件开发的成果体现,包括技术文档、管理文档和用户文档。 ⑥软件配置管理与软件质量管理,包括配置规划、软件变更控制、软件版本控制和质量控制计划。
?软件工程》课程既强调基本概念和基本知识的理解和掌握,又侧重软件项目的分析、设计、实现和维护的基本技能。比较注意“点”和“面”的结合。我还是蛮喜欢这门课的,通过对这门课的学习让我意识到理论学习很重要,实践更重要,实践是检验真理的唯一标准,只有将理论与实际结合,才更能发挥我们所学的知识的作用,更能直接的创造效益,社会和国家做出贡献。
软件工程心得体会6篇相关文章:
★ 简易工程合同6篇
★ 小型工程合同6篇
★ 工程补充合同6篇