软件工程心得体会.docx

软件工程心得体会.docx

《软件工程心得体会.docx》由会员分享，可在线阅读，更多相关《软件工程心得体会.docx（7页珍藏版）》请在冰豆网上搜索。

软件工程心得体会

软件工程心得体会

【篇一：

软件工程实习心得体会】

软件工程实习心得体会

软件工程实习心得体会〔一〕

在这次软件工程课程中，我学到了很多东西，第一次深刻的体会到了什么叫做用工程化的思想来编写软件，以前自己也写过一些小型软件，没有做过大型的项目，直到这次课堂我担任组长并组织组员共同完成“个人图书管理系统”这个项目，第一次和别人合作，才发现运用工程化的思想来做是如此的有必要。

从这里，我才真正的意识到实施一个软件工程并不是说简单的会编码就能够解决问题的，我们更多的精力不是放在编码上，编码只是一个很小的模块，只占到那么小的一个部分。

这个事实在很大程度上颠覆了我以前的思想，在我以前的认识中，似乎整个软件就是编码，除此无它，还好有老师的指导，不然真的会出现老师所说的，撞得头破血流之后才想起来用软件工程的思想来完成这个工作。

刚真正开始工作之前，我们费了很多的时间来完成一些前端工作，如需求分析和可行性分析，这块工作在别人看来可能是相对无关紧要，甚至是多于的，其实，换做在以前，我也会这么认为。

可是，我现在算是深深地明白了磨刀不误砍柴工的道理，这些工作的完成太有必要了，太重要了，要想你的软件有用有市场，能被别人接受和认可，在进行过程中不会出现崩溃性的问题，这些工作缺一不可。

还有就是接下来的一些设计模块，此模块与软件编码涉及比较紧密，主要是解决一些参数传递和接口通讯的问题，此模块对我的触动远没有上两个模块对我的影响大，因此再次也不做过多的介绍。

在整个活动的完成过程中，作为组长，我收获很多，我发现，要是组里有个人不怎么想做事情时，他对于整个组织的影响是消灭性的，正所谓“一颗老鼠屎，能坏一仓谷”，以后我的组织里要是出现这样的人，我绝不会给他继续留下来的时机，我会在第一时间将他清除出去。

还有就是，作为组长，你要做的最重要的事情，不是发挥自己的聪明才智，而是创造出一个平台，让别人去发挥，你所要做得，出了保证这个平台的完整性和公平性外，还有就是协调好各组员之间的关系。

这就是我的实习感想。

软件工程实习心得体会〔二〕

时间过的很快，转眼间已经实习将近5个月，其中有2个月是属于完全被流放的。

最先在内部系统组参与内部管理系统开发（struts+mysql+spring+hibernate），之后是去做网络交换机软件的脚本测试。

现在又回归内部系统，虽然在脚本组期间，编码能力被别人甩在后头，但至少具有了一些测试经验。

至少自己做的东西，是真正交付到了客户手上，到也稍微有些成就感。

1、浅谈测试

一直以来，我都认为测试是脱离了软件工程范围的工作，不以为屑。

但在实际情况中，测试是既重要且难以精湛的.其真正的压力，在于找不到bug，责任在你，而不在于编码人员。

一般的测试人员不懂编码，他们靠的是日以累计的经验总结和想象力。

而要做到高级测试工程师，则一定要懂编码，因为这是你完全掌握整个系统的方方面面具体运作的前提。

但占主导地位的，还是大型系统的集成测试经验。

实际项目中，编码时间一般只占30%左右，真正消耗时间的是it阶段的找bug与对应bug，此阶段基本评定了coder的编码质量。

2、程序员的困惑

有些人，以为教学视频和代码看多，自己就懂的多，实际做起来，却不知从何下手，

问题在那?

如何定位?

如何解决?

通通跟一样能力有关，debug追踪能力，也称调试。

在项目组工作不愁源码资源，但问题是蛋糕摆在面前，你如何去消化?

有位同事告诉我：

代码看几遍都没用，要去抄，例如一个查询模块，在此基础上去做具体记录的历史记录查询模块，你可能会觉得很简单，但实际情况却往往报一堆异常，配置问题涉及到方方面面，以及数据库字段，传值问题等等，一大堆对于新人来说很郁闷的问题。

但不用怕，只要学会调试，一个个问题去追踪，一个个去解决，自然而然，那段“源码”才真正属于你。

3、如何调试追踪

如果你能在短短的时间内就看到问题点在那，放下断点去追踪，出去找工作，绝对没问题。

出现问题的时候，不要光看代码，要用实际行动去追踪运行期间的具体值，那是最好途径。

eclipse是个很爽的ide，这点做的很好。

例如页面内容显示不是自己想要的数据，我们要先从数据库查询语句去下手，设置断点，一步一步stepover，让sql字段（存取最终sql语句的字符串）运行到有值，inspect进去看，如果还看不出来，就点击它，copy后在sql客户端去实际运行，看看实际查询出来的表是什么，如果是对的，有可能就是页面调用的错误或者action逻辑的传值问题。

页面错误的调试，基本方法是用右键点击实际网页查看源代码，copy到editplus，就能看到具体错误发生在那几行。

通常有几种常见的错误，例如：

缺少对象这种很多时候是有些被你调用的字段有可能为空的情况出现的，可以加if（xxx=null）语句加保护。

追踪的方法基本就是用alert语句，放在有可能出错的地方。

4、一些习惯

遇到问题先自己思考，无从下手再找高手帮助看看，注意他帮你看的思路，别在一旁闲着，看多了自己也会了，不然你一辈子都停留在那种水平，从人身上学到的东西远远比书多的多。

解决了一个问题后，要去究根问底去找到问题产生的起因，以防你下次遇到类似的问题再浪费同样的时间。

把代码写的漂亮，注释、空行、标准一样不能少，可读性是放在第一位。

曾经看过一个高手写的代码，真的一看就是不同水平的人写的，几乎很完美，读起来很流畅，方便自己也方便别人。

任务完后不要呆着，去要求经理给你更有挑战性的任务，只要你肯去尝试，他们就会对你另言相看，把三天的任务一天加班搞定，效率和忠诚都有了，路也比较好走了。

【篇二：

软件工程心得体会】

读软件工程案例教程有感

对于学习软件工程这门课程，我认为有许多东西要学习。

其实在我看来学习这门课程的精髓是学习一种方法。

是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。

读完软件工程案例教程这本书，我觉得自己受益匪浅。

整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、电脑工程、需求分析、结构化分析建模以及基于uml面向对象分析建模和测试等。

对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。

一．需求分析

一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。

当用户有一个问题可以用电脑系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。

由此我们可以看出需求分析的重要性。

需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。

对需求的获取往往有错误的认识：

用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。

首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。

其次是对问题的理解，用户对电脑系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是很明显的信息。

最后是

需求确实认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。

为了克服以上的问题，必须有组织的执行需求的获取活动。

〔1〕需求分析必须能够表达和理解问题的数据域和功能域。

数据域包括数据流、数据内容和数据结构，而功能域反映上述3方面的控制信息。

〔2〕需求分析要把一个复杂问题按功能进行分解并逐层细化。

通常，软件系统要处理的问题如果太大、太复杂就很难理解，假设划分成几部分，并确定各部分间的接口，就可完成整体的功能。

在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。

〔3〕需求建模。

模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。

〔1〕确定详细的需求，否则经费就算不准。

经费估计错误的原因多为：

用户需求频繁变动、遗漏重要需求、与用户交流不够、需求规格说明书质量低劣、需求分析不充分等。

〔2〕在编写需求规格说明书之前，应明确要解决的问题。

在试图解决问题之前，要保证已考察了全部可替代的方案。

要搞清哪地方有问题，真正的问题出在哪里。

这样，在编写需求规格说明书时做到有的放矢，把存在的问题暴露出来。

〔3〕立即确定需求，并记录下该需求的背景。

没有明确问题，就进行下一步的设计，想回避矛盾，可能会带来更大的问题。

用户不确定需求，软件设计人员自己决定需求，将会带来严重的问题。

为了防止将来可能出现的问题和软件工程项目能够尽快地进入到下一个阶段的系统设计中，要尽可能迅速地把用户需求确定下来。

任何决定总比没有决定要好。

〔4〕一旦在需求规格说明书中发现问题，立即改正。

如果把存在的问题拖延到系统设计阶段去改正，就可能要花数倍的时间和精力才能纠正同一错误。

〔5〕在众多用户需求中确定各个需求的优先顺序，并确定可能存在的子集，以便为软件设计、实施和项目管理等后续阶段提供有利条件。

〔6〕需求分析时，不要进行系统设计的工作。

需求分析的主要目的是确定软件系统的外部特征，充分反映软件系统应有的面貌，便于让软件设计人员根据

用户需求，去全面地考虑软件系统的体系结构、算法等。

在需求分析阶段要集中精力解决用户需求存在的问题，尽可能防止产生遗留问题。

〔7〕对于复杂的软件系统，要从多种视角进行需求分析。

根据软件系统的本质，切合实际地组织多种视角的需求。

例如，可从根据用户的类型，或根据响应的类型，或根据对象的软件工程案例教程类型，或根据系统的模式等视角来组织用户需求。

通过多个视角来研究用户需求问题，把可得到的不同的“投影”组合起来形成完整系统的描述。

当试图从整体观点来描述软件系统发生困难，或者有可能发生错误，或者很有可能遗失软件系统的某些特性。

而从不同的视角来描述软件系统，因为每个视角限制了研究的范围并能够将注意力集中于此，所以很容易保证所研究的问题是真正完整的。

〔8〕重视形式化方法，但不放弃自然语言。

为了用户需求表达的精确性和方便用户的可理解性，一个好方法是把自然语言的表达与形式化规格说明并立，互相对照，而且在一般情况下，先用自然语言写出，再给出它的形式模型。

〔9〕用户需求中不应存在“待确定”的条款。

如假设有这种需要，应同时说明：

何时由谁来解决该问题。

需求分析是从用户最初的非形式化需求到满足用户要求的软件产品的映射过程。

它实际上是一个对用户意图不断进行揭示和判断的过程，其目的在于细化、精化软件的作用范围，确定拟开发软件的功能和性能、约束、环境等。

可将用户的需求分为两大类：

功能性需求和非功能性需求。

〔2〕非功能性需求。

非功能性要求主要从各个角度对所考虑的可能的解决方案起约束和限制作用。

在软件工程中，常用的需求分析方法有面向数据流的结构化分析方法〔简称sa〕和面向对象的分析方法〔简称ooa〕。

此外，还有以用户为中心的需求分析

方法。

这些方法都采用图文结合的方式，可以直观地描述软件的逻辑模型。

这里仅介绍结构化分析方法和以用户为中心的需求分析方法。

软件本身无形态，它是复杂的知识高度密集的逻辑产品，其中不可能没有错误。

软件实施工程过程中必须伴随着软件质量保证的活动，而软件测试是主要活动之一。

在开发软件的过程中，人们使用了许多保证软件质量的方法分析、设计和实现软件，但难免还会在工作中犯错误。

这样，在软件产品中就会隐藏许多错误和缺陷。

对于规模大、复杂性高的软件更是如此。

在这些错误中，有些是致命的错误，如果不排除，就会导致生命与财产的重大损失。

测试的目的是“说明程序能正确地执行应有的功能”，还是“说明程序没有错误”？

基于不同的立场，存在着两种完全不同的测试目的。

从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可以接受该产品。

而从软件开发者的角度出发，则希望测试成为说明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。

因此，他们会选择那些导致程效概率小的测试用例，回避那些易于暴露程序错误的测试用例。

同时，也不会刻意去检测、排除程序中可能包含的副作用。

显然，这样的测试对完善和提高软件质量毫无价值。

因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。

如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。

如果站在用户的角度，替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。

在选取测试用例时，考虑那些易于发现程序错误的数据。

〔1〕应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

由于原始问题的复杂性、软件的复杂性和抽象性、软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。

所以不应把软件测试仅仅看成是软件开发的一个独立阶段，

而应当把它贯穿到软件开发的各个阶段中。

在需求分析阶段就应该制订测试计划，以保证每个需求，每个设计单元都是可测试的，便于测试。

坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。

〔2〕测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

测试以前应当根据测试的要求，选择在测试过程中使用的测试用例〔testcase〕。

测试用例主要用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。

如果对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。

〔3〕程序员应防止检查自己的程序。

测试工作需要严格的作风、客观的态度和冷静的情绪。

自己测试自己的软件不容易发现错误，程序员应防止测试自己的程序。

测试是一种“挑剔性”的行为，人们常常由于各种原因具有一种不愿否认自己工作的心理，认为揭露自己程序中的问题总不是一件愉快的事，这一心理状态就成为测试自己程序的障碍。

心理状态和思维定式是测试自己程序的两大障碍，应由别人或另外的机构来测试程序员编写的程序。

另外，程序员对软件规格说明理解错误而引入的错误则更难发现。

如果由别人来测试程序员编写的程序，可能会更客观、更有效，并更容易取得成功。

要注意的是，这点不能与程序的调试〔debugging〕互相混淆，调试由程序员自己来做可能更有效。

〔4〕在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的、临界的、可能引起问题变异的输入条件。

在测试程序时，人们常常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应该做的事情，而无视了不合法的和预想不到的输入条件。

事实上，软件在投入运行以后，用户的使用往往不遵循事先的约定，使用了一些意外的输入，如用户软件工程案例教程在键盘上按错了键或打入了非法的命令。

如果开发的软件遇到这种情况时不能做出适当的反应，给出相应的信息，那么就容易产生故障，轻则给出错误的结果，重则导致软件失效。

因此，软件系统处理非法命令的能力也必须在测试时受到检验。

用不合理的输件测试程序时，往往比用合理的输入条件进行测试能发现更多

【篇三：

软件工程实习心得体会】

软件工程实习心得体会〔一〕在这次软件工程课程中，我学到了很多东西，第一次深刻的体会到了什么叫做用工程化的思想来编写软件，以前自己也写过一些小型软件，没有做过大型的项目，直到这次课堂我担任组长并组织组员共同完成“个人图书管理系统”这个项目，第一次和别人合作，才发现运用工程化的思想来做是如此的有必要。

从这里，我才真正的意识到实施一个软件工程并不是说简单的会编码就能够解决问题的，我们更多的精力不是放在编码上，编码只是一个很小的模块，只占到那么小的一个部分。

这个事实在很大程度上颠覆了我以前的思想，在我以前的认识中，似乎整个软件就是编码，除此无它，还好有老师的指导，不然真的会出现老师所说的，撞得头破血流之后才想起来用软件工程的思想来完成这个工作。

刚真正开始工作之前，我们费了很多的时间来完成一些前端工作，如需求分析和可行性分析，这块工作在别人看来可能是相对无关紧要，甚至是多于的，其实，换做在以前，我也会这么认为。

可是，我现在算是深深地明白了磨刀不误砍柴工的道理，这些工作的完成太有必要了，太重要了，要想你的软件有用有市场，能被别人接受和认可，在进行过程中不会出现崩溃性的问题，这些工作缺一不可。

还有就是接下来的一些设计模块，此模块与软件编码涉及比较紧密，主要是解决一些参数传递和接口通讯的问题，此模块对我的触动远没有上两个模块对我的影响大，因此再次也不做过多的介绍。

在整个活动的完成过程中，作为组长，我收获很多，我发现，要是组里有个人不怎么想做事情时，他对于整个组织的影响是消灭性的，正所谓“一颗老鼠屎，能坏一仓谷”，以后我的组织里要是出现这样的人，我绝不会给他继续留下来的时机，我会在第一时间将他清除出去。

还有就是，作为组长，你要做的最重要的事情，不是发挥自己的聪明才智，而是创造出一个平台，让别人去发挥，你所要做得，出了保证这个平台的完整性和公平性外，还有就是协调好各组员之间的关系。

这就是我的实习感想。

软件工程实习心得体会〔二〕时间过的很快，转眼间已经实习将近5个月，其中有2个月是属于完全被流放的。

最先在内部系统组参与内部管理系统开发（struts+mysql+spring+hibernate），之后是去做网络交换机软件的脚本测试。

现在又回归内部系统，虽然在脚本组期间，编码能力被别人甩在后头，但至少具有了一些测试经验。