下面是范文网小编收集的软件工程培训心得6篇 对于软件工程的心得体会，以供参考。
软件工程培训心得1
时间过的很快，转眼间已经实习将近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、一些习惯
遇到问题先自己思考，无从下手再找高手帮忙看看，注意他帮你看的思路，别在一旁闲着，看多了自己也会了，不然你一辈子都停留在那种水平，从人身上学到的东西远远比书多的多。
解决了一个问题后，要去究根问底去找到问题产生的起因，以防你下次遇到类似的问题再浪费同样的时间。
把代码写的漂亮，注释、空行、规范一样不能少，可读性是放在第一位。曾经看过一个高手写的代码，真的一看就是不同水平的人写的，几乎很完美，读起来很流畅，方便自己也方便别人。
任务完后不要呆着，去要求经理给你更有挑战性的任务，只要你肯去尝试，他们就会对你另言相看，把三天的任务一天加班搞定，效率和忠诚都有了，路也比较好走了。
软件工程培训心得2
学习了这门课程，还有老师们的多元化教课，不但让我从理论上掌握软件工程，还有从不同的实例，让理论和实践得到了很好的结合。整一个学期下来，总的来说还是学到了很多东西的，有很多地方是值得肯定的，其实在我看来，软件工程与其说是一门课程，不如说是一门思想。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。
整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模等。接着我就详细介绍下我对这门课程知识点的理解概括：
软件：软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和使用的文档。
软件的特征：
①软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。
②软件是通过人们的智力活动，把知识与技术转化成信息的一种产品。
③软件成为产品后，其生产只是简单的拷贝，不同于硬件制造。
④维护过程比硬件复杂的多，甚至会引发新的错误。
软件危机：指的是软件开发和维护过程中遇到的一系列严重问题。
出现软件危机的原因：
①软件维护费用急剧上升，直接威胁计算机应用的扩大。
②软件生产技术进步缓慢。
软件工程是指导计算机软件开发和维护的工程学科。
软件生存周期：一个软件从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生存周期。
软件的生存周期可分为八个阶段：
①问题定义；
②可行性研究；
③需求分析；
④总体（概要）
设计；
⑤详细设计；
⑥编码与单元测试；
⑦综合测试；
⑧软件维护；
瀑布模式：是传统的软件开发模式，其中的“瀑布”是对这个模式的形象表达，由山顶倾泻下来的水，自顶向下、逐渐细化。其特点是：线性化过程；分为分析、设计、编码、集成等几个阶段，并且各阶段逐级推进，不允许跨越。里程碑管理；阶段评审；文档驱动；简洁便于工程应用的线性化过程步骤，并可以通过里程碑管理机制而使项目进程量化。其明显的优点就是没个阶段结束前都要对所完成的阶段成果进行评审，这使得软件的错误能够在个阶段内尽早发现并尽早解决，总的来说瀑布模式具有良好的质量保证机制，有很强的生命力。
原型进化模式：对软件进行直接模拟或仿真，只需要分析需求框架后进行原型创建，再对原型系统进行逐步细化与完善，通过版本更新逐步满足用户对于软件的多方面需要。
增量模式：开发过程有三个任务域，分别是设计结构、开发构件和集成系统，它既有完善的工程管理机制，又能适应用户需求变更，有利于质量的监控，并且各局部基于构件构造，有利于逐步构建与完善；由于先交付核心构件可利于降低项目的技术风险。
螺旋模式：是一种可较好的规避开发风险过程的模式，项目是基于任务的螺旋式推进，每个螺旋由内之外分别是需求分析、软件设计、系统集成、验证与交付。
软件开发的整个过程：
①需要项目团队，组建优秀的团队可以开发出更搞质量的软件产品。任务开发团队要求小而精，成员大多在8人以内，主要成员有项目负责人、开发人员、资料管理员和软件测试员。
②项目计划是为了使软件开发各项工作有秩序地进行，包括任务分配和基于里程碑的进度安排，甘特图和任务网络图是用来描述进度计划的工具。项目计划书可以作为软件开发的工作指南。
③项目成本估算，由于项目有来自各方面的成本包括工资开支、场地费、差旅费、设备费和资料费等，但是软件主要是对人力成本的估算，常用的方法有程序代码成本估算法等。
④软件风险管理包括很多不确定的风险因素，如计划风险、管理风险、需求风险、技术风险、人员风险、产品风险、用户风险和商业风险等等，而风险管理的主要任务是：风险识别、风险评估、和风险防范。
⑤软件文档管理，软件文档是工程模式软件开发的成果体现，包括技术文档、管理文档和用户文档。
⑥软件配置管理与软件质量管理，包括配置规划、软件变更控制、软件版本控制和质量控制计划。
计算机系统由硬件、软件、数据资源、网络资源、使用系统的人等诸多元素。
有三种典型的计算机体系结构：
①主机结构，主机集中了全部智能，并依靠终端接口与外部设备连接。
②Client/Server结构，智能分布于服务器与客户机，并依靠网络连接成系统，其中，服务器处于核心位置，提供被动核心服务；客户机处于边缘位置，可主动访问服务器，寻求服务支持。
③Browser/server结构，可适应互联网远程交互的特殊结构，基于Web服务器构建。
需求分析：系统开发前期需求分析很重要，它是为了有效解决用户问题的需要进行的一项工程活动，所需要考虑的需求问题是功能需求、数据需求、性能需求和接口需求，开发者承担分析任务，核心是用户。
其步骤有三个：
①获取客户需求，客户泛指某个人或机构部门等，一般方法是调查，包括访谈、座谈、问卷、跟班和收集资料，需求规约可表达用户的软件价值。
②建立需求模型，它是用户需求的图解，一些常用的模型有：业务树图、用例图、活动图。分别用于结构化需求建模、系统业务举例和反映系统工作流程。
③进行需求验证，要验证的主要内容有：有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。结构化分析建模：它是建立在需求规约基础上的，对软件问题进行全面解说，包括四个方面：
①数据建模，它与数据库设计密切相关，ER图涉及实体、关系、属性等图形元素，在业务层面建立数据库概念模型，一般用于前期的建模构想。
②功能建模，是对系统数据加工的图解，数据流程图是常用的建模工具，涉及数据接口、数据处理、数据流、数据存储等图形元素，用于描述系统数据加工细节。
③行为建模，行为模型用于说哦名软件系统与环境的交互，状态转换图常用的软件行为建模工具涉及状态、事件等图形元素。⑤数据字典，是用于定义软件的元素，使软件元素获得严肃的、详密的、精确的规格说明。需求分析模型中的数据、功能、行为等诸多方面的元素，都有必要通过数据字典给予细节说明，以达到对系统较完整全面的规格定义。
基于UML对象面向对象分析建模：UML是统一建模语言，有统一的语法、语义和语用规则，其建模过程的特点是：用例驱动、以构架为中心和增量迭代，通过包实现对模型的有效的一体化管理。
包括三部分：
①用例建模，它面向用户需求的，能够反映系统的用户价值，用例图的基本元素有用例、参与者、交流；用例之间有泛化、延伸和包含关系。
②活动建模，活动图用于描述系统动态过程，主要图形元素有：活动、转换、起点、终点、判断、并发、同步、泳道等。可描述高层业务级活动，涉及整个业务流程，针对每个用例活动建模，反映用例内部活动细节。
③类分析建模，这里就只考虑实体类，实体类所代表的数据相互之间通常有一定的关系，依靠这种关系可形成有组织的程序数据结构。实体类之间的主要数据关系有：关联、聚类、泛化。
接下来我就简单说下我上这门课的简单的心得体会，我们是大四的学生了，也只有这个学期有课了，刚开始课表安排出来的时候觉得挺意外的，只有前八周有课，当时我还是有点小感动的，大四事情很多，有要考研的和工作的，大家也都有各自的事情，如果有16周的课，那么每周课不是特别多，但是时间特别分散，也不能集中某段时间去做什么事情。但是相对于老师的压力也有，课程压缩了相当于每节课的教学任务大大增加了，在加上有些假期冲掉课，就感觉我们好像上课学不到什么东西，也只是一些关键的和考试挂钩的才重点讲，完全没有扩展的时间和空间了。但是总的来说，学校开了这门课，我们上了这门课，总是学到了点东西的，不可能明明上了软件工程这门课，却像没上一样什么都不懂。在上课的时候我还是很认真地去听老师所讲述的内容的，我觉得他的思想和我一向而来的培养计算机学生综合素质的理解还是在一定程度上不谋而合了，所谓的需求获取，那就是一个谈判，辩论，交流的过程，已经不是单纯的编编程序就能解决的问题了。从我所看到的听到的来说，我最怕的就是计算机系的学生被别人说成是个带着厚眼镜的，只能够在电脑前编编程序的，在交际场上不知道说什么而一个字都说不出来的人。我觉得这样的人进入社会之后是没有什么前途的，起码他们缺乏了与人沟通交流的能力。而这门课程在一定程度上给了我们这些学生一个机会来锻炼自己在另一方面的能力，设想一下，一个又有技术又能够与人交流合作的人所取得的成就自然要比一个单单只会编程序的人要大得多。其次，这门课程教给了我们在完成一个实际项目时的一般程序及过程，我认为这是一份非常具有实际意义的教学内容。当我们在毕业之后，这是我们实际要运用的一项非常有用的技能，而且不仅仅局限于软件工程的范畴，我们即使是从事与其它行业，不也是要从需求获取开始，一直有条有理地到最后成品的出炉吗？应该说这就是这门课的价值所在。无论是在上课，还是在学生会里面做学生工作，我都深深地感觉到，技术性的工作就好比变魔术，其实原理是非常简单的，甚至可以说简单的可笑，但是当你就是做出这么一个简单的东西出来之后，一些外行们有时候会用崇拜的眼光看着你，觉得你很厉害，很高深莫测。但是制作的过程他们却不知道，也许知道之后他们只是会哑然失笑，原来这个东西的制作过程是如此的简单。这个可以说就是技术的魅力了，而作为需求获取及之后的一系列过程则是类似于魔术揭秘的过程，但是作为这个秘密我们并不需要一揭到底，至于揭的程度如何那就是我们那就是我们学出的程度如何了，我们要让对方知道我们在做什么？以及如何去做？这些东西需要我们以一定的技巧叙述出来，所起到的作用就是能够让对方了解自己的进度，却又能够不让对方来干涉自己的工作过程。因为我们是技术员，对方只是外行，即使对方知道了这个魔术的操作过程，也并不代表他们就能够向变着魔术的我们来随便修改这个魔术的变法，况且我们能够用不同的过程来得出一个同样的结果，这个过程的得出的主动权如何掌握在我们的手上，就看我们如何以高明的方式来揭开这个魔术的谜底了。当然了，在纯粹的理论上，我觉得开设这样一门课程是很成功的。但是毕竟现实里有太多的不确定的因素。最重要的因素就是授课的老师和听课的学生。这两个可以说是这门课成与败的决定性的因素。
作为我们学生来说，应该负起比较主要的责任。在大学里有了太多的基础课程，基础课程大多都比较枯燥无味，也许在第一个学期里我们还能够保持着新鲜感，但是在6学期之后，可以说再有新鲜感就是一件比较困难的事情了，我们都已经开始变得迟钝了。其次的，没有认识到这门课程的价值。这门课的价值我已经在上面说过了，是不言而喻的。但是并不是每个同学毕业之后都回从事计算机行业，也不是每个同学都知道这门课程的意义已经不仅仅局限于计算机这个范畴。或许有些人觉得反正以后不是这个发展方向，也就不在乎这个课程吧。我个人觉得这门课确实是挺好的，如果认真学必能学到很多东西，动手实践能力和从整个大体分析系统开发的逻辑性思维也会明显增强，不管以后从事哪个方面的工作，这对以后来说都是一笔很大的隐性财富。说到我自己对这么课的学习，还是有点愧疚的，前面四周我每周每节课都去上的，并且上课也认真听，一边听老师讲课一边自己看书本的介绍，但是后来我上这门课的次数就降低了，因为觉得时间很紧吧，而且老师上课的节奏我个人觉得有点慢，我都可以自己预习看到后面去了，但是这门课我还是每周至少上一节课的，虽然我早上7点多一点就出门，在自习室，但是有时候明明知道到了上课的时间，明明上课的地方离自习的地方不远也不太想去。我记得有次上课时候老师生气了，说来上课的人少，我仔细环顾了下四周发现确实人很少，稀稀疏疏的分散着，看起来确实不太舒服，让我不得不反思了，这大学的教育到底怎么了，怎么到了大四大家都不来上课，虽然我不是每节课都来，但是我还是时不时来上课的，可能是比较浮躁吧，快毕业了，觉得上课学不到什么实际的东西，要么实际一点好好考研继续深造，要么去培训增强实践能力这样才能较好的为找个满意的工作做好铺垫。
《软件工程》课程既强调基本概念和基本知识的理解和掌握，又侧重软件项目的分析、设计、实现和维护的基本技能。比较注意“点”和“面”的结合。我还是蛮喜欢这门课的，通过对这门课的学习让我意识到理论学习很重要，实践更重要，实践是检验真理的唯一标准，只有将理论与实际结合，才更能发挥我们所学的知识的作用，更能直接的创造效益，社会和国家做出贡献。
软件工程培训心得3
软件是计算机系统中与硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。软件工程（SoftwareEngineering，简称为SE）是针对软件这一具有特殊性质的产品的工程化方法。SE涵盖了软件生命周期的所有阶段，并提供了一整套工程化的方法，来指导软件人员的工作。任何事物都是从无到有的，软件当然也不例外。上世纪中期，软件产业从零开始起步，经过半个多世纪的发展，其大致经历的3个阶段：程序设计阶段、软件设计阶段和软件工程时代，现已成为推动人类社会发展的龙头产业，随着信息化时代的发展，软件对人类社会也将越看来越重要。人们对软件的认识自然经历了一个由浅入深的过程，在得到巨大需求的同时，也遇到了一系列严重问题，即软件危机。所谓软件危机，是指在计算机软件的开发和维护过程中所遇到的一些严重问题，其实质是软件产品的供应赶不上需求的增长。概括的说包含两方面的问题：一、如何开发软件，以满足不断增长，日趋复杂的要求；二、如何维护数量不断膨胀的软件产品。为研究和解决软件危机，一门新兴的学科软件工程，应运而生。
软件工程的概念是为了有效地控制软件危机的发生而被提出来的，它的中心目标就是把软件作为一种物理的工业产品来开发，要求“采用工程化的原理与方法对软件进行计划、开发和维护”，它的主要对象是大型软件，它的最终目的是摆脱手工生产软件的现状，逐步实现软件开发和维护的自动化。软件工程的概念自提出来后，经过几十年的发展，虽然软件危机没有得到彻底的解决，但在软件开发方法和技术方面已经有了很大的进步，提出了软件工程知识体系、软件工程三段论、软件工程生存期模型、服用原则等等。
软件开发过程大致经过7个阶段：可行性分析、需求分析、概要设计、详细设计、编码、测试、提交与维护。接下来逐一分析本人见解：
一、可行性分析：顾名思义，就是看项目究竟“能不能做”。有3个方面：技术可行性、经济可行性和操作可行性。要确定项目，首先要客观的、科学的了解项目的规模、难度和时间限制，才可以确定应该投入多少人力、物力和财力去做这个项目，必须准确的估计项目的规模与难度。看项目是否有价值去做，如果没有价值，就放弃；如果有价值，就要看目前的资源是否能满足项目的开发。如果项目有价值，且有必需的资源，那么就可以确定能做这个项目了。
二、需求分析阶段：解决“做什么、不做什么”的问题。围绕两个核心问题开展需求分析：应该了解什么？通过什么方式去了解？
1、了解什么：应该先了解宏观的问题，再了解细节的问题。最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适的技术来实现此需求。同时，需求说明不可有额二义性，更不能前后矛盾，如果有二义性货前后相矛盾，则要重新分析此需求。然后，选择合适的生存周期，建立合适的需求模型；
2、通过什么方式去了解：直接与客户交谈；有些需求客户讲不清楚，分析人员又猜不透，这是就要请教行家。需求分析是非常重要的阶段，如果做不好的话，后果很麻烦。
三、概要设计：解决“怎么做”的问题。将需求描述的“做什么”问题变为一个实施方案的创造性过程，使得整个项目在逻辑上和物理上能够得意实现。概要设计是第一个开发活动，也是最重要的活动，是软件项目实现的关键阶段。设计质量的高低直接决定了软件项目的成败，缺乏或者没有软件设计的过程会产生一个不稳定的、甚至是失败的软件系统。一个良好的软件设计是进行快速软件开发的根本，没有良好的设计，会将时间花在不断的调试上，无法添加新功能，修改时间越来越长，随着给程序打上一个有一个的补丁，新的功能需要更多的代码实现，就变成一个恶性循环了。概要设计是软件设计级别中的高级设计，是从需求出发，描述了总体上系统架构应该包含的要素。概要设计尽可能模块化，因此描述了各个模块之间的关联，主要是根据需求规格或规格定义，合理、有效地实现产品规格中定义的各项需求，完成软件模块的划分并描述模块之间的关系，并不断分解系统模块，从高层分解到低层分解。它注重框架设计、总体结构设计、数据库设计、接口设计、网络环境设计等，将产品分割成一些可以独立设计和实现的部分并保证各个部分可以和谐的工作。此过程中画数据流图、IPO图、E-R图、界面设计等。
四、详细设计：解决“具体做什么”的问题，将解决问题的办法进行具体化。软件设计的低级设计，亦即详细设计，主要描述实现各个模块的算法和数据结构以及用特定计算机语言实现的初步描述，是针对程序开发部分来说的，但这个阶段不是真正编写程序，而是设计
出程序的详细规格说明，这种规格说明类似于其他工程领域中工程师经常使用的工程蓝图，程序员根据其中所包含的必要的细节写出实际的程序代码。用另一种方式说就是，详细设计是将概要设计的框架内容具体化、明细化，将概要设计转化为可以操作的软件模型，但在实际项目进行过程中，依据项目的具体情况和项目要求，这个过程可能可以省略（逻辑上没有省略，表现在概要设计阶段或者编码阶段），直接按照概要设计进行编码；不过，个人认为最好有，有详细设计可以更好的保证编码顺利的进行，可以预先扫清编码过程中的障碍，提高代码的质量和编码的效率。主要包括模块描述、算法描述、数据描述，可以采用图形、表格或者文字描述等方式表达出来。
五、编码：实现项目。由项目的概要设计和详细设计，将设计变为代码需要通过编码过程来完成。实现设计有很多种选择，有很多实现语言、工具等可供选择，但一般而言，在设计中会直接或间接地确定了实现语言。编码过程的一个主要标准时变成与设计的对应性和统一性。如果编码没有按设计的要求进行，设计就失去意义了。设计过程中的算法、功能、接口、数据结构都应该在编码过程中体现。如果需求发生变更，设计业对应地发生变更，同时代码也应该一致地发生变更，这可以通过配置管理配置控制。可见，如果编码和设计不一致，很容易“跑偏”，走火入魔。编码时要严格遵循编码标准和规范，并提供必要的程序注释，增加可读性。另一个就是重构的理解，所谓重构是对软件内部的一种调整，目的是在不改变软件基本功能和性能的前提下，提高其可理解性，降低成本，当添加功能、修改代码和复查
代码的时候，更不要错过重构，另外，重构可以和设计互补。还有一点值得注意，要在必要的时候部署编码文档。
六、测试：看软件是否符合标准。软件编码完成之后，将软件提交给用户之前，需要对软件进行测试，这是保证软件产品质量的一个重要标准，也是评估产品质量的主要手段。软件测试是从软件工程中演化出来的一个分支，有着非常广泛的内容，并且随着软件产业的发展，它已经变得越来越重要。软件与生俱来就可能存在缺陷，为了防止和减少这些可能存在的缺陷，进行软件测试是有必要的，测试是最有效的的排错和防止缺陷和故障的手段。最原始的测试莫过于直接运行软件了，后来测试手段逐渐多样化。测试手段有静态测试、动态测试面向对象的测试、自动化测试等等之分。静态测试或称静态分析是指一种不通过执行程序来进行测试的一种技术，主要是检查软件的表示和描述是否一致，覆盖程序的编码格式、程序语法、检查独立语句的结构和使用等，主要包括代码检查、静态结构分析、代码质量等等，可以通过人工进行，亦可借助工具（如：语法分析器）自动进行。动态测试是运行被测试的程序，通过输入测试用例，对其运行情况进行分析，以达到检测的目的，显然动态测试封像我们通常意义上的“测试”。动态测试主要包括白盒测试、黑盒测试、灰盒测试（介于黑盒和白盒之间）。其他测试不再一一介绍。
七、提交与维护：测试完之后，就要把软件交给用户使用了。提交不是剪裁，给人家就行了，还要教会客户怎么使用这个系统。如果用户不会使用系统，就会不满意系统的性能，那之前的努力就白费了，
打水漂了。为了保证成功地将我们开发的软件提交给用户，我们需要对用户进行培训，同时提交必要的文档及用户手册软件。维护就不用多说了，就是售后服务了。维护需要分析人员、编码人员和设计人员等角色的参与，有纠错行维护、适应性维护、完善性维护、预防性维护等。维护后，要写软件维护过程文档，至少提交一个软件维护记录。以上是软件工程及其几个阶段的介绍，知道怎样开发软件只是软件工程的一部分，搞好团队合作也是很重要的。项目是一个很大的工程，需要一个团队的统筹规划，团结协作，集思广益，举一反三，才能够按预期完成。
软件工程培训心得4
在这次软件工程课程中，我学到了很多东西，第一次深刻的体会到了什么叫做用工程化的思想来编写软件，以前自己也写过一些小型软件，没有做过大型的项目，直到这次课堂我担任组长并组织组员共同完成“个人图书管理系统”这个项目，第一次和别人合作，才发现运用工程化的思想来做是如此的有必要。
从这里，我才真正的意识到实施一个软件工程并不是说简单的会编码就能够解决问题的，我们更多的精力不是放在编码上，编码只是一个很小的模块，只占到那么小的一个部分。这个事实在很大程度上颠覆了我以前的思想，在我以前的认识中，似乎整个软件就是编码，除此无它，还好有老师的指导，不然真的会出现老师所说的，撞得头破血流之后才想起来用软件工程的思想来完成这个工作。
刚真正开始工作之前，我们费了很多的时间来完成一些前端工作，如需求分析和可行性分析，这块工作在别人看来可能是相对无关紧要，甚至是多于的，其实，换做在以前，我也会这么认为。可是，我现在算是深深地明白了磨刀不误砍柴工的道理，这些工作的完成太有必要了，太重要了，要想你的软件有用有市场，能被别人接受和认可，在进行过程中不会出现崩溃性的问题，这些工作缺一不可。
还有就是接下来的一些设计模块，此模块与软件编码涉及比较紧密，主要是解决一些参数传递和接口通讯的问题，此模块对我的触动远没有上两个模块对我的影响大，因此再次也不做过多的介绍。
在整个活动的完成过程中，作为组长，我收获很多，我发现，要是组里有个人不怎么想做事情时，他对于整个组织的影响是毁灭性的，正所谓“一颗老鼠屎，能坏一仓谷”，以后我的组织里要是出现这样的人，我绝不会给他继续留下来的机会，我会在第一时间将他清除出去。还有就是，作为组长，你要做的最重要的事情，不是发挥自己的聪明才智，而是创造出一个平台，让别人去发挥，你所要做得，出了保证这个平台的完整性和公平性外，还有就是协调好各组员之间的关系。
这就是我的实习感想。
软件工程培训心得5
一、需求分析和概要设计。
1）需求分析
按照软件工程的软件过程来说：
1需求分析产生了软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白，开发人员也可据此进行下面的工作（概要设计）。
2.概要设计产生了软件概要设计说明书，说明系统模块划分、选择的技术路线等，整体说明软件的实现思路。并且需要指出关键技术难点等。
在进行需求分析时，我们既是开发者又是用户，本系统的业务流程与业务分类的定义比较难。我们的团队进行了研讨，还充分运用了身边的各种资源，大量的查找了很多网络上关于工资系统的资料。通过资料的进行讨论、根据我们的课题进行分析，最后确定了用户的需求为：
1.本系统在高校应用后高校工资管理方面的教职工将减少至目前的50%左右；
2.本系统在高校应用后将在高校各方面的成本将会有所降低；
3.本系统在高校应用后将教职工的工资达到完全透明，计算更加精确教职工因纠纷事件减少到1%。 根据分析将系统的功能从一般教职工与系统管理者两个角度将功能划分为7个模块，当然介于我们的知识有限，有的功能没有实现：员工工资与考勤直接挂钩，但本系统无法与员工考勤系统挂钩相连，由于涉及此系统时该高校并没有员工考勤系统，而且我们在最初进行商量的时候也没有提出该要求。
2）概要设计
从概要阶段开发正式进入软件的实际开发阶段，本阶段完成系统的大致设计并明确系统的数据结构与软件结构。在软件设计阶段主要是把一个软件需求转化为软件表示的过程，这种表示只是描绘出软件的总的概貌。由概要设计说产生大的概要说明书的目的就是进一步细化软件设计阶段得出的软件总体概貌，把它加工成在程序细节上非常接近于源程序的软件表示。
在本阶段主要涉及处理流程的设计、总体结构和模块外部设计、功能分配。在接口设计上有用户接口、外部接口、内部接口；数据结构设计有逻辑结构设计、物理结构设计等等。在接口设计时参考了大量的资料。
最后就是编写文档――软件需求说明书、概要分析说明书。
而文档的作用在于：一是可以帮助整理思路。把要完成的目标，系统的结构，每一个模块的功能等整理一下，然后分门别类地写下来，这样在开发的过程中，就有据可依，在需要回过头来修改设计的时候，也有证可考。二是便于交流。三是可以作为以后维护时的参考资料。
三、软件工程课程设计――心得体会
我们进行了为期一周的课程设计。通过这次课程设计，我拓宽了知识面，锻炼了能力，综合素质得到较大提高。安排课程设计的基本目的，在于通过理论与实际的结合、人与人的沟通，进一步提高思想觉悟。尤其是观察、分析和解决问题的实际工作能力，以便培养成为能够主动适应社会主义现代化建设需要的高素质的复合型人才。作为整个学习体系的有机组成部分，课程设计虽然安排在一周进行，但并不具有绝对独立的意义。它的一个重要功能，在于运用学习成果，检验学习成果。运用学习成果，把课堂上学到的系统化的理论知识，尝试性地应用于实际设计工作，并从理论的高度对设计工作的现代化提出一些有针对性的建议和设想。检验学习成果，看一看课堂学习与实际工作到底有多大距离，并通过综合分析，找出学习中存在的不足，以便为完善学习计划，改变学习内容与方法提供实践依据。对我们信息管理与信息系统专业的学生来说，实际能力的培养至关重要，而这种实际能力的培养单靠课堂教学是远远不够的，必须从课堂走向实践。这也是一次预演和准备毕业设计工作。通过课程设计，让我们找出自身状况与实际需要的差距，并在以后的学习期间及时补充相关知识，为求职与正式工作做好充分的知识、能力准备，从而缩短从校园走向社会的心理转型期。课程设计促进了我系人才培养计划的完善和课程设置的调整。
在一个星期的课程设计之后，我们普遍感到不仅实际动手能力有所提高，更重要的是通过对软件开发流程的了解，进一步激发了我们对专业知识的兴趣，并能够结合实际存在的问题在专业领域内进行更深入的学习。
软件工程课程虽已结束，但我对于软件工程的学习才刚刚开始。我体会到项目管理的重要性，随着软件规模、复杂度的不断增加，项目开发中更多的是协作、管理和控制。我学习到很多一般性的方法，例如：需求获取、模块化、计划等等。同时，我也认识到使用计算机解决实际问题的复杂性，人们认识表达的过程不断反复、逐步深化，软件工程方法要提供给程序员们一种更加有效的对客观世界问题域进行形式化的过程方法。
软件工程培训心得6
软件工程是一门实践性很强、交叉性很强的学科，它提供给我们的不仅是一种方法论，更是一种世界观。
在没有接触软件工程这门课时，我一直认为软件就是程序。能编出解决问题的程序就ok了，从没有想过，在写一个程序之前还要构思几份文档（可行性分析、需求分析、概要设计）。不过对于那些大型软件如植物僵尸大战（至少对于我来说是比较大型的了）怎么去实现它，想得我一头雾水。绚丽的界面、40种植物、一大堆不同类型的僵尸，怎样编代码去实现它呢？
第一次上软件工程的课，裴老师问“软件是什么？” 我的第一想法是：这个问题太过愚昧了！谁不知道软件就是程序呀？ “软件是由计算机程序、数据及文档组成。”听到这句话，我心里先是一惊，慌忙翻了下书“软件是程序和所有使程序正确运行所需的相关文档和配置信息。”赫然映入我眼帘。突然间我发现，就算是植物僵尸大战这样复杂的游戏，如果设计者实现分模块把每一部分如何实现用文档描叙出来，那这个软件实现起来不是很容易吗？
第一次课后我明白了软件工程是致力于专业化软件开发的理论、方法和工具的研究。虽然我从初中开始信息奥赛，高中继续这个爱好，但在大学二年级下学期才接触在软件开发中这么有引导意义的学科，不觉有种相见恨晚的感觉。自然它的方法学三要素：方法、工具、过程，我牢记于心。
短短的四周，裴老师的课给我留下了深刻的印象，印象尤深的是：
做软件我们首先考虑的是团队的实力。
如果别人给你50万让你们团队开发一个软件，如果他要求你们团队给这个软件永久维护，那么你要去跟他协商付100万。很多软件公司倒闭就是因为维护上的问题。至此我才明白维护软件是软件生存周期中时间最长的一个阶段，它是最花费精力与钱财的一个阶段。
如果将来你们碰到了我，你跟我说你是se那么我会很高兴，如果你告诉我你是软件工程师，我只会“嗯嗯”两下。
其实在我接触软件后，渴望的是当一名软件工程师。现在才知道学软件工程专业后，去当一名软件工程师是最低层的也是最没“技术”含量的。要做就做系统构架师，当然这需要我们的不懈努力才能达到。系统构架师的职责是设计一个公司的基础构架，并提供关于怎样建立和维护系统的指导方针。恍然发现学软件不仅是学软件，相关的管理能力也是需要具备的。
当然理论知识是用来指导实践的，亲身体验才能领悟软件工程的妙用。课设我们选择了图书馆管理系统，主要是这个系统我们接触比较多，对于它的流程还是比较清楚的。虽然如此我们还是花了很大的时间去完成它。记得当时我们定下这个题目是晚上，在讨论用什么语言实现时，大家各自说出自己比较善于的语言。然后均衡了下，定下用java做开发语言。在实现过程中，突然发现java环境连接数据库和tomcat超级麻烦且数据库老是连接不上。趁时间还早我们三再次讨论，决定用c#做开发语言，主要是c#相对于c++与java来说简易写。同时我们定下不管以后遇到什么困难都要坚持下去的准则。在课设期间我们没少跑图书馆，查阅各种资料，对比各本书上实现图书馆管理系统的代码。终于在4月11日把所有课设的所有事情弄好了。当然这只是个概述。
我印象尤深记忆深厚的是最初实现文档那块。刚开始，软件工程这门课还没学多少，基本的设计理念就很模糊。文档到底该怎么写，很纠结。于是我从网上狂下相关文档。通过粘贴与复制终于一份内容乱七八糟的需求分析文档出来了，当然这只是用来借鉴的。后来孟阳分享了十三份关于文档这方面的模板。我们照着那个样子在结合团队项目的相关实例开始了文档的写作。我们的文档总是一个人先写好，再拿给另一个人改，最后由第三个人评审。大家都觉的可以了，才过关。测试报告虽然是我一个人完成了，但也经历了不少时间，当然这时间是按小时算的。首先把大体写出了，然后修改，再增加信息。大量的截图以及思考怎样用例超费脑子，两天的通宵，彻底把我搞垮了，不过在文档出炉后，心里异常开心。
软件工程课程虽已结束，但我对于软件工程的学习才刚刚开始，裴老师的课让我受益匪浅。我体会到项目管理的重要性，随着软件规模、复杂度的不断增加，项目开发中更多的是协作、管理和控制。我学习到很多一般性的方法，例如：需求获娶模块化、分治、估算、计划等等。同时，我也认识到使用计算机解决实际问题的复杂性，在图灵机模型和冯?诺依曼体系的计算机框架下，人们认识表达的过程（不断反复、逐步深化）和计算机的实现过程（顺序执行）相差甚远，软件工程方法要提供给程序员们一种更加有效的对客观世界问题域进行形式化的过程方法。
向se进军！至少这是现在的目标。
谢谢裴老师！您的课通俗易懂，举的例子贴近生活，让我们易于接受。
软件工程培训心得6篇 对于软件工程的心得体会相关文章：