软件工程心得体会.docx

《软件工程心得体会.docx》由会员分享，可在线阅读，更多相关《软件工程心得体会.docx（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件工程心得体会软件工程心得体会 本文关键词：软件工程，心得体会软件工程心得体会 本文简介：读软件工程案例教程有感对于学习软件工程这门课程，我认为有很多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应当说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。整本书的内容逻辑软件工程心得体会 本文内容：读软件工程案例教程有感对于学习软件工程这门课程，我认为有很多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应当说其范畴已经远远不止局限

2、于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。整本书的内容逻辑很清楚明白，由浅入深按部就班，首先我就也许描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深化分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面对对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感爱好，在这我要着重的谈一些自己的心得体会以及自己的看法。1需求分析1.1需求分析的重要性一款胜利的软件是建立在胜利的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作

3、。当用户有一个问题可以用计算机系统来解决，而开发人员起先帮助用户解决这个问题，沟通就起先了。由此我们可以看出需求分析的重要性。需求获得可能是最困难、最关键、最易出错及最须要沟通沟通的活动。对需求的获得往往有错误的相识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业须要就可以了，但是事实上需求获得并不是想象的这样简洁，这条沟通之路布满了荆棘。首先需求获得要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细微环节，这样造成了系统目标的混淆。其次是对问题的理解，用户对计算机系统的实力和限制缺乏了解，任何

4、一个系统都会有许多的用户或者不同类型的用户，每个用户只知道自己须要的系统，而不知道系统的整体状况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清晰那些工作可以交给软件完成，他们不清晰需求是什么，或者说如何以一种精确的方式来描述需求，他们须要开发人员的帮助和指导，但是用户与开发人员之间的沟通很简单出现障碍，忽视了那些被认为是“很明显“的信息。最终是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必需有组织的执行需求的获得活动。1.2需求分析的原则（1）需求分析必需能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域

5、反映上述3方面的限制信息。（2）需求分析要把一个困难问题按功能进行分解并逐层细化。通常，软件系统要处理的问题假如太大、太困难就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。（3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。1.3需求分析的留意事项（1）确定具体的需求，否则经费就算不准。经费估计错误的缘由多为：用户需求频繁变动、遗漏重要需求、与用户沟通不够、需求规格说明书质量低劣、需求分析不充分等。（2）在编写需求规格说明书之前，应明

6、确要解决的问题。在试图解决问题之前，要保证已考察了全部可替代的方案。要搞清哪地方有问题，真正的问题出在哪里。这样，在编写需求规格说明书时做到有的放矢，把存在的问题暴露出来。（3）马上确定需求，并记录下该需求的背景。没有明确问题，就进行下一步的设计，想回避冲突，可能会带来更大的问题。用户不确定需求，软件设计人员自己确定需求，将会带来严峻的问题。为了避开将来可能出现的问题和软件工程项目能够尽快地进入到下一个阶段的系统设计中，要尽可能快速地把用户需求确定下来。任何确定总比没有确定要好。（4）一旦在需求规格说明书中发觉问题，马上改正。假如把存在的问题拖延到系统设计阶段去改正，就可能要花数倍的时间和精力

7、才能订正同一错误。（5）在众多用户需求中确定各个需求的优先依次，并确定可能存在的子集，以便为软件设计、实施和项目管理等后续阶段供应有利条件。（6）需求分析时，不要进行系统设计的工作。需求分析的主要目的是确定软件系统的外部特征，充分反映软件系统应有的面貌，便于让软件设计人员依据用户需求，去全面地考虑软件系统的体系结构、算法等。在需求分析阶段要集中精力解决用户需求存在的问题，尽可能避开产生遗留问题。（7）对于困难的软件系统，要从多种视角进行需求分析。依据软件系统的本质，切合实际地组织多种视角的需求。例如，可从依据用户的类型，或依据响应的类型，或依据对象的软件工程案例教程类型，或依据系统的模式等视角

8、来组织用户需求。通过多个视角来探讨用户需求问题，把可得到的不同的“投影”组合起来形成完整系统的描述。当试图从整体观点来描述软件系统发生困难，或者有可能发生错误，或者很有可能遗失软件系统的某些特性。而从不同的视角来描述软件系统，因为每个视角限制了探讨的范围并能够将留意力集中于此，所以很简单保证所探讨的问题是真正完整的。（8）重视形式化方法，但不放弃自然语言。为了用户需求表达的精确性和便利用户的可理解性，一个好方法是把自然语言的表达与形式化规格说明并立，相互比照，而且在一般状况下，先用自然语言写出，再给出它的形式模型。（9）用户需求中不应存在“待确定”的条款。如若有这种须要，应同时说明：何时由谁来

9、解决该问题。1.4用户需求的类型需求分析是从用户最初的非形式化需求到满意用户要求的软件产品的映射过程。它事实上是一个对用户意图不断进行揭示和推断的过程，其目的在于细化、精化软件的作用范围，确定拟开发软件的功能和性能、约束、环境等。可将用户的需求分为两大类：功能性需求和非功能性需求。（1）功能性需求。功能性需求主要说明白系统各功能部件与环境之间的相互作用的本质，即拟开发软件在职能上实际应做到什么。一般来说，它是用户最主要的需求，通常包括系统的输入、系统能完成的功能、系统的输出以及其他反应。在功能性需求中还应包括备选功能的定义识别。（2）非功能性需求。非功能性要求主要从各个角度对所考虑的可能的解决

10、方案起约束和限制作用。1.5需求分析的方法在软件工程中，常用的需求分析方法有面对数据流的结构化分析方法（简称SA）和面对对象的分析方法（简称OOA）。此外，还有以用户为中心的需求分析方法。这些方法都采纳图文结合的方式，可以直观地描述软件的逻辑模型。这里仅介绍结构化分析方法和以用户为中心的需求分析方法。2.软件测试2.1软件测试概述软件本身无形态，它是困难的学问高度密集的逻辑产品，其中不行能没有错误。软件实施工程过程中必需伴随着软件质量保证的活动，而软件测试是主要活动之一。在开发软件的过程中，人们运用了很多保证软件质量的方法分析、设计和实现软件，但难免还会在工作中犯错误。这样，在软件产品中就会隐

11、藏很多错误和缺陷。对于规模大、困难性高的软件更是如此。在这些错误中，有些是致命的错误，假如不解除，就会导致生命与财产的重大损失。2.2软件测试的目的测试的目的是“说明程序能正确地执行应有的功能”，还是“表明程序没有错误”？基于不同的立场，存在着两种完全不同的测试目的。从用户的角度动身，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度动身，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信念。因此，他们会选择那些导致程效概率小的测试用例，回避那些易于暴露程序错误的测试用例。同时，也不会刻意去检测、

12、解除程序中可能包含的副作用。明显，这样的测试对完善和提高软件质量毫无价值。因为在程序中往往存在着很多预料不到的问题，可能会被疏漏，很多隐藏的错误只有在特定的环境下才可能暴露出来。假如不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。假如站在用户的角度，替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。在选取测试用例时，考虑那些易于发觉程序错误的数据。2.3软件测试的原则（1）应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。由于原始问题的困难性、软件的困难性和抽象性、软件开发各个阶段工作的多样性，以及参与开发各种层次人员之间工

13、作的协作关系等因素，使得开发的每个环节都可能产生错误。所以不应把软件测试仅仅看成是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。在需求分析阶段就应当制订测试安排，以保证每个需求，每个设计单元都是可测试的，便于测试。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发觉和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。（2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。测试以前应当依据测试的要求，选择在测试过程中运用的测试用例（TestCase）。测试用例主要用来检验程序员编制的程序，因此不但须要测试的输入数据，而且须要针对这些输入数据的预

14、期输出结果。假如对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。（3）程序员应避开检查自己的程序。测试工作须要严格的作风、客观的看法和冷静的心情。自己测试自己的软件不简单发觉错误，程序员应避开测试自己的程序。测试是一种“挑剔性”的行为，人们经常由于各种缘由具有一种不愿否定自己工作的心理，认为揭露自己程序中的问题总不是一件开心的事，这一心理状态就成为测试自己程序的障碍。心理状态和思维定式是测试自己程序的两大障碍，应由别人或另外的机构来测试程序员编写的程序。另外，程序员对软件规格说明理解错误而引入的错误则更难发觉。假如由别人来

15、测试程序员编写的程序，可能会更客观、更有效，并更简单取得胜利。要留意的是，这点不能与程序的调试（Debugging）相互混淆，调试由程序员自己来做可能更有效。（4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异样的、临界的、可能引起问题变异的输入条件。在测试程序时，人们经常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应当做的事情，而忽视了不合法的和预想不到的输入条件。事实上，软件在投入运行以后，用户的运用往往不遵循事先的约定，运用了一些意外的输入，如用户软件工程案例教程在键盘上按错了键或打入了非法

16、的吩咐。假如开发的软件遇到这种状况时不能做出适当的反应，给出相应的信息，那么就简单产生故障，轻则给出错误的结果，重则导致软件失效。因此，软件系统处理非法吩咐的实力也必需在测试时受到检验。用不合理的输件测试程序时，往往比用合理的输入条件进行测试能发觉更多的错误。小结：经过一学期的软件工程的学习，深刻感到其重要性的同时也学到了不少的东西，将对我在今后的软件开发过程中起极大的作用。第10页 共10页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页