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