软件工程实验心得体会.docx

软件工程实验心得体会.docx

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

软件工程实验心得体会

软件工程实验心得体会

软件工程试验心得体会1

　　曾经看过一本书叫《道法自然》，内容略记得一二，但我最观赏的是它的书名。

软件设计没什么太神奇有东西，只要专心体会，其实一切都很自然。

软件的设计之“道”，也不在于设计有多么的华美、精致，而在于其朴实、自然，最终到达“以无招胜有招”，进入一个全新的境界。

　　一、软件设计理论的层次

　　以我的拙见，软件设计领域中的各种概念，可以分为以下几个层次来进展理解：

　　1、软件设计的目的：

重用性、扩展性。

　　这是最高的层次，是应对软件危机的须要。

　　2、设计原那么：

低耦合、高聚合。

　　各种软件设计的原那么，如依靠倒置原那么、单一职那么原那么、面对接口等，以及各种设计模式，其根本的目的其实只是为了降低耦合这么简洁。

因为只有低耦合才能更好的适应改变，更好的重用和扩展。

　　3、实现方法：

运用设计模式封装改变、降低耦合。

　　设计模式只是用来“封装改变、降低耦合”的工具而已。

它是面对对象设计时代的产物，其本质就是充分运用面对对象的三个特性，即：

封装、继承和多态，进展敏捷的组合运用。

　　二、关于耦合

　　1、耦合的粒度

　　耦合无论如何也是不行幸免的。

当我们实现接口、继承父类的时候，就会不行幸免的产生耦合。

耦合是有不同粒度的，我们解耦到什么粒度为止，我认为应以模块的重用粒度为准。

尽量解除重用模块或对象之间的耦合。

而重用模块之内的耦合，应属于聚合的范畴，所以不要盲目的去解耦，否那么就陷入了误区。

　　2、解耦的原理

　　怎样才能解耦呢，或者说为什么各种设计模式能到达解耦的目的呢？

我觉得有以下几个思路：

　　〔1〕将详细的东西抽象处理

　　〔2〕将分散的东西集中处理

　　而面对对象中的接口、继承正为我们供应了这样的一种机制。

通过访问接口或基类或抽象类，而不是详细的实现类，从而与详细的实现类到达了解耦的目的。

我们还可以设计一些限制类，像润滑剂一样，协调各实现类之间的访问，也可以到达耦的目的。

　　事实上，各种设计模式的根本思想也就是这样。

创立型模式是为了解除创立对象时产生的耦合，事实上是解除对类称名的依靠，而构造型和行为型是为了解除对象属性或方法的干脆调用。

不管什么设计模式，都是将对详细实现类的访问提升为对接口、基类或用于协调的限制类的访问。

　　三、关于接口

　　这一节更详细，谈一谈接口，因为运用接口是软件设计的重要手段，但已经不属于“道”了~

　　1、接口与继承

　　接口描述的是对象某一个方面行为特征。

运用接口与运用继承关系各有优缺点，运用子类继承可以继承父类的功能，表达了重用的精神。

而接品更加敏捷，因为它解除了子类与父类之间的高度耦合，它表达在敏捷扩展的精神。

　　2、接口与纯虚类

　　理论上接口可以由纯虚基类实现类似的功能，那为什么还我们不去掉接口的概念，而干脆运用虚类呢？

　　接口存在的理由就是它更加敏捷，关系简洁，易于理解。

比方一个类可以实现十几个甚至几十个接口，但一般开发工具只支持单继承〔由于多继承太简单导致混乱和冲突〕，假如要继承十几层，系统构造想必会无法理解了，我以为这是接口存在的最重要的缘由。

　　假如接口和虚类继承结合运用，可以产生强大的威力，这也是很多设计模式的“杀手锏”。

　　以上算是总结一下自己的心得。

确定有不少片面之处，请各位指教。

软件工程试验心得体会2

　　早在我选择民政职业技术学院就读软件开发与工程管理这门专业的时候，我始终认为软件开发无非是努力的敲代码，从敲代码的过程中去体会各行代码的意思和用处，在没学软件工程时我始终都是努力的敲代码去学习软件开发这门专业。

在大一的时候我敲代码的激情很好，但是到大二的时候就出现问题了，我根本就不喜爱敲代码了，望见代码就头疼。

所以感觉厌恶这门专业，对学习也不感爱好了。

而且，还有一件更头疼的事是在写一个简洁的程序时竟然老是出错，难一点的，困难一点的程序竟然无从下手。

但是去看程序的参考答案时都看得懂，又感觉很简单。

学了软件工程以后，我就感觉我以前的学习方法是错误的。

以前我只注意于代码，而不注意理论学问以及编程的思路，程序的架构。

以至于在些程序时没有写程序的思路，不能形成程序的架构。

只想到看脑袋里是否有与此类似的代码。

越想程序越乱，最终脑袋里一片空白。

不知道程序从哪个方面下手了。

　　软件工程这门课程是做软件开发的人必学的课程，通过学这门课程，程序员就会注意软件开发的理论学问，以及做工程开发的思路。

学了这门课程后你写程序就不会去盲目的去套用代码，而是理清此程序的架构以及思路。

程序该从什么时候起先，什么时候完毕。

在中间须要添加什么样的功能，以完善该软件。

其实学软件工程并不难，而且很简单。

软件工程与日常生活联系起来的话，就是在一天中你该先做什么，后做什么。

理解了先做什么，后做什么了以后写程序就不是那么难了，再困难的程序也可以分成几大块。

你理清程序的思路后就可以一步步的解决其中的难题，最终实现软件的功能。

假如没学软件工程不知道理清程序的思路的话，做一个大的工程开发，那么多的代码，没有一个很好的构造，最终只会导致程序混乱，错误百出，知道代码再多也会素手无策的。

　　总而言之，作为一个程序员学习软件工程这门课程是至关必要的，假如没学习软件工程，你就不会做工程开发，也不行能开发出一个完善的软件出来。

软件工程试验心得体会3

　　经过这学期软件工程试验的学习，深深感到用户需求对软件的重要性。

胜利的软件产品是建立在胜利的需求根底之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。

当用户有一个问题可以用计算机系统来解决，而开发人员起先协助用户解决这个问题，沟通就起先了。

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

对需求的获得往往有错误的相识：

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

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

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

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

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

　　需求获得活动要完成的任务或者步骤的过程如下：

　　1、编写工程视图和范围文档

　　系统的需求包括四个不同的层次：

业务需求、用户需求和功能需求、非功能性需求。

业务需求说明白供应给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求，它们在工程视图与范围文档中予以说明。

用户需求文档描述了用户运用产品必需要完成的任务，这在运用实例文档或方案脚本说明中予以说明。

功能需求定义了开发人员必需实现的软件功能，使得用户能完成他们的任务，从而满意了业务需求。

　　非功能性需求是用户对系统良好运作提出的期望，包括了易用性、反响速度、容错性、强健性等等质量属性。

需求获得就是依据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。

工程视图和范围文档就是从高层次上描述系统的业务需求，应当包括高层的产品业务目标，评估问题解决方案的商业和技术可行性,全部的运用实例和功能需求都必需遵从的标准。

而范围文档定义了工程产品所包括的全部工作及产生产品所用的过程。

工程相关人员对工程的目标和范围能达成共识,整个工程组都应当把留意力集中在工程目标和范围上。

　　2、用户群分类

　　系统用户在许多方面存在着差异，例如：

运用系统的频度和程度、应用领域和计算机系统学问、所运用的系统特性、所进展的业务过程、访问权限、地理上的布局以及个人的素养和喜好等等。

依据这些差异，你可以把这些不同的用户分成不同的用户类。

与ULM中Usecase的Actor概念一样，用户类不必须都指人，也可以包括其他应用系统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。

将用户群分类并归纳各自特点，并具体描述出它们的特性特点及任务状况，将有助于需求的获得和系统设计。

　　3、建立核心队

　　通常用户和开发人员不自觉的都有一种我们和他们的想法，产生一种对立关系，把彼此放在对立面，每一方都定义自己的边界，只想自己的利益而忽视对方的想法。

他们通过文档、记录和对话来沟通，而不是作为一个合作的整体去识别和确定需求完成任务。

实践证明这样的方法是不正确的，不会给双方带来一点好处,良好的沟通关系没有建立导致了误会和忽视重要的信息。

只有当双方参加者都明白要胜利自己须要什么，同时也知道要胜利对方须要什么时，才能建立起一种合作关系。

　　为了建立合作关系通常采纳一种组队的方式来获得需求，建立一个由用户代表和开发人员组成的联合小组作为需求获得的核心队伍。

联合小组将负责识别需求、分析解决方案和协商分歧，小组成员可以采纳会议、电子邮件、综合办公系统等方式进展沟通，但沟通时应留意以下原那么：

小组会议应当由中立方来组织和主持，用户和开发人员都要参与;沟通预先要确定打算和参加的规那么;议题要明确并覆盖全部关键点，但信息来源应当自由;沟通目标要明确，并告知全部的成员。

　　4、确定运用实例

　　从用户代表处收集他们将运用系统完成所需任务的描述，探讨用户与系统间的交互方式和对话要求，这就是运用实例，一个单一的运用实例可能包括完成某项任务的很多逻辑相关任务和交互依次。

运用实例方法给需求获得带来的好处来自于该方法是用以任务为中心和以用户为中心的观点，比起运用以功能为中心和以开发者为中心的方法，运用实例方法可以运用户更清晰地理解和相识到新系统允许他们做什么和怎么做。

描写运用实例的时候要留意运用简洁直白的表述，尽量运用主动语态，用系统或者用户作为主语，比方用户提交用户密码，系统验证用户密码是否正确，还有一点在描述中不要设计界面细微环节，比方用户从下拉框中选择产品类型。

运用实例为以后写用例场景描述中的根本路径和扩展路径供应了素材。

　　5、分析用户工作流程

　　分析用户工作流程视察用户执行业务任务的过程，通过分析运用实例得到系统的用例图。

编制用例图文档将有助于明确系统的运用实例和功能需求，统一建模语言的运用有助于与用户进一步沟通。

每个用例的描述应包括：

编号,为每个用例安排一个唯一的编号，为需求的追溯供应了便利;参加者，与这个用例交互的actor;前置条件，起先用例前所必需具备的系统状态;后置条件，用例完成后系统到达的状态;根本路径，用例完成的关键路径，也是用户期望的路径;扩展点，根本路径的分枝，表示意外状况;字段说明，路径中名称的进一步分讲解明，对以后类属性的定义和数据库字段设计起作用;设计约束，实现用例的非功能约束。

　　6、检查问题报告

　　通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本供应了大量丰富的改良及增加特性的想法，负责供应用户支持及协助的人能为收集需求过程供应极有价值的信息。

　　7、需求重用

　　假如客户要求的功能与已有的系统很相像，那么可查看需求是否有足够的敏捷性以允许重用一些已有的软件组件。

业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。

　　总结：

经过一学期的软工试验，深刻感到其重要性的同时也学到了不少的东西，将对我在今后的软件开发过程中起极大的作用。