软件工程实验心得

第一篇：软件工程实验心得

早在我选择民政职业技术学院就读软件开发与项目管理这门专业的时候，我一直认为软件开发无非是努力的敲代码，从敲代码的过程中去体会各行代码的意思和用处，在没学软件工程时我一直都是努力的敲代码去学习软件开发这门专业。在大一的时候我敲代码的激情很好，但是到大二的时候就出现问题了，我根本就不喜欢敲代码了，看见代码就头疼。所以感觉厌恶这门专业，对学习也不感兴趣了。而且，还有一件更头疼的事是在写一个简单的程序时竟然老是出错，难一点的，复杂一点的程序竟然无从下手。但是去看程序的参考答案时都看得懂，又感觉很容易。学了软件工程以后，我就感觉我以前的学习方法是错误的。以前我只注重于代码，而不注重理论知识以及编程的思路，程序的架构。以至于在些程序时没有写程序的思路，不能形成程序的架构。只想到看脑袋里是否有与此类似的代码。越想程序越乱，最后脑袋里一片空白。不知道程序从哪个方面下手了。

软件工程这门课程是做软件开发的人必学的课程，通过学这门课程，程序员就会注重软件开发的理论知识，以及做项目开发的思路。学了这门课程后你写程序就不会去盲目的去套用代码，而是理清此程序的架构以及思路。程序该从什么时候开始，什么时候结束。在中间需要添加什么样的功能，以完善该软件。其实学软件工程并不难，而且很容易。软件工程与日常生活联系起来的话，就是在一天中你该先做什么，后做什么。理解了先做什么，后做什么了以后写程序就不是那么难了，再复杂的程序也可以分成几大块。你理清程序的思路后就可以一步步的解决其中的难题，最终实现软件的功能。如果没学软件工程不知道理清程序的思路的话，做一个大的项目开发，那么多的代码，没有一个很好的结构，最终只会导致程序混乱，错误百出，知道代码再多也会素手无策的。

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

软件工程实验心得（2）：

曾经看过一本书叫《道法自然》，内容略记得一二，但我最欣赏的是它的书名。软件设计没什么太神秘有东西，只要用心体会，其实一切都很自然。软件的设计之“道”，也不在于设计有多么的华丽、精巧，而在于其朴实、自然，最终达到“以无招胜有招”，进入一个全新的境界。

一、软件设计理论的层次

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

1、软件设计的目的：重用性、扩展性。

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

2、设计原则：低耦合、高聚合。

各种软件设计的原则，如依赖倒置原则、单一职则原则、面向接口等，以及各种设计模式，其根本的目的其实只是为了降低耦合这么简单。因为只有低耦合才能更好的适应变化，更好的重用和扩展。

3、实现方法：运用设计模式封装变化、降低耦合。

设计模式只是用来“封装变化、降低耦合”的工具而已。它是面向对象设计时代的产物，其本质就是充分运用面向对象的三个特性，即：封装、继承和多态，进行灵活的组合运用。

二、关于耦合

1、耦合的粒度

耦合无论如何也是不可避免的。当我们实现接口、继承父类的时候，就会不可避免的产生耦合。耦合是有不同粒度的，我们解耦到什么粒度为止，我认为应以模块的重用粒度为准。尽量解除重用模块或对象之间的耦合。而重用模块之内的耦合，应属于聚合的范畴，所以不要盲目的去解耦，否则就陷入了误区。

2、解耦的原理

怎样才能解耦呢，或者说为什么各种设计模式能达到解耦的目的呢?我觉得有以下几个思路：

(1)将具体的东西抽象处理

(2)将分散的东西集中处理

而面向对象中的接口、继承正为我们提供了这样的一种机制。通过访问接口或基类或抽象类，而不是具体的实现类，从而与具体的实现类达到了解耦的目的。我们还可以设计一些控制类，像润滑剂一样，协调各实现类之间的访问，也可以达到耦的目的。

事实上，各种设计模式的基本思想也就是这样。创建型模式是为了解除创建对象时产生的耦合，实际上是解除对类称名的依赖，而结构型和行为型是为了解除对象属性或方法的直接调用。不管什么设计模式，都是将对具体实现类的访问提升为对接口、基类或用于协调的控制类的访问。

三、关于接口

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

1、接口与继承

接口描述的是对象某一个方面行为特征。使用接口与使用继承关系各有优缺点，使用子类继承可以继承父类的功能，体现了重用的精神。而接品更加灵活，因为它解除了子类与父类之间的高度耦合，它体现在灵活扩展的精神。

2、接口与纯虚类

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

接口存在的理由就是它更加灵活，关系简单，易于理解。比如一个类可以实现十几个甚至几十个接口，但一般开发工具只支持单继承(由于多继承太容易导致混乱和冲突)，如果要继承十几层，系统结构想必会无法理解了，我以为这是接口存在的最重要的原因。

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

以上算是总结一下自己的心得。肯定有不少片面之处，请各位指教。

第二篇：软件工程实验的心得体会

软件工程实验的心得体会

---- 获取用户需求的沟通技巧

经过这学期软件工程实验的学习，深深感到用户需求对软件的重要性。成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。

需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。

其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。

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

1、编写项目视图和范围文档

系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

非功能性需求是用户对系统良好运作提出的期望，包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解决方案的商业和技术可行性,所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上。

2、用户群分类

系统用户在很多方面存在着差异，例如：使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素质和喜好等等。根据这些差异，你可以把这些不同的用户分成不同的用户类。与ulm中usecase的actor概念一样，用户类不一定都指人，也可以包括其他应用系统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点，并详细描述出它们的个性特点及任务状况，将有助于需求的获取和系统设计。

3、建立核心队

通常用户和开发人员不自觉的都有一种"我们和他们"的想法，产生一种对立关系，把彼此放在对立面，每一方都定义自己的"边界"，只想自己的利益而忽略对方的想法。他们通过文档、记录和对话来沟通，而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的，不会给双方带来一点益处,良好的沟通关系没有建立导致了误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么，同时也知道要成功对方需要什么时，才能建立起一种合作关系。

为了建立合作关系通常采取一种组队的方式来获取需求，建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧，小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流，但交流时应注意以下原则：小组会议应该由中立方来组

织和主持，用户和开发人员都要参加；交流预先要确定准备和参与的规则；议题要明确并覆盖所有关键点，但信息来源应该自由；交流目标要明确，并告知所有的成员。

4、确定使用实例

从用户代表处收集他们将使用系统完成所需任务的描述，讨论用户与系统间的交互方式和对话要求，这就是使用实例，一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。使用实例方法给需求获取带来的好处来自于该方法是用以任务为中心和以用户为中心的观点，比起使用以功能为中心和以开发者为中心的方法，使用实例方法可以使用户更清楚地理解和认识到新系统允许他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述，尽量使用主动语态，用"系统"或者"用户"作为主语，比如"用户提交用户密码，系统验证用户密码是否正确"，还有一点在描述中不要设计界面细节，比如"用户从下拉框中选择产品类型"。使用实例为以后写用例场景描述中的基本路径和扩展路径提供了素材。

7、分析用户工作流程

分析用户工作流程观察用户执行业务任务的过程，通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求，统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括：编号,为每个用例分配一个唯一的编号，为需求的追溯提供了方便；参与者，与这个用例交互的actor；前置条件，开始用例前所必须具备的系统状态；后置条件，用例完成后系统达到的状态；基本路径，用例完成的关键路径，也是用户期望的路径；扩展点，基本路径的分枝，表示意外情况；字段说明，路径中名称的进一步分解说明，对以后类属性的定义和数据库字段设计起作用；设计约束，实现用例的非功能约束。

5、检查问题报告

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

6、需求重用

如果客户要求的功能与已有的系统很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。

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

第三篇：软件工程实验报告

《软件工程》课程实验报告

实验名称：教务管理系统之子系统——学院课程安排

姓名：

院 （系）：软 件 学 院

专业班级：

学号：

指导教师：

地点：

成绩：

时间：2014 年 10月 日 至 2014 年 11月 8 日

1.实验目的

确定项目的可实施性，获取项目的需求，并在此基础上完成系统的逻辑功能模型的建立，了解软件工程中需求分析阶段的主要活动和需求分析文档描述的主要内容，掌握利用数据流图描述系统功能需求的方法，正确应用数据字典。增进对软件工程的理解，学会系统的分析软件的构成，掌握并理解软件从确立到测试等一系列过程。

2.实验内容

1. 系统简介

每个学期的期中，学校教务处向各个学院发出下各学期的教学计划，包括课程名称、课程代码、课时、班级类别（本科、专科、成人教育、研究生）、班号等；学院教学主管人员根据教学任务和要求给出各个课程的相关限制（如：任课教师的职称、上课的班数、最高和最低周学时数等）；任课教师自报本人授课计划，经所在教研室协调任可，将教学计划上交学院主管教学计划的人员，批准后上报学校教务处，最终由教务处给出下个学期全学院教师的教学任务书。

假设上述排课过程全部由人工操作，现要求为上述过程实现计算机自动处理过程。

2. 限定条件

a) 每位教师的主讲课程门数不超过2门/学期：讲师以下职称的教师不能承担学院定主课的主讲任务。

b) 学院中层干部的主讲课时不能超过4学时/周。

c) 本学期出现严重教学事故的教师不能承担下各学期的主讲任务。

d) 本系统的输入项至少包括：教务处布置的教学计划，学院教师自报的授课计划和学院定的有关授课限制条件。

e) 本系统的输出项至少包括：教务处最终下达全院教师的教学任务书和学院各个班级下各学期的课程表（可以不含上课地点）。

项目数据流图

系统的分析“教务管理系统之子系统——学院课程安排”的组成、结构和实现步骤，明白项目的业务流程图，绘制数据流图（dfd），数据模型（er），编写数据字典（dd），数据加工处理的描述，撰写需求规格说明书

3.实验步骤

1.

2.

3.

4.

5. 对图书管理系统进行分析，整合用户权限和操作 根据用户操作流程画出系统流程图 对系统做出概要分析，拟定开发流程 绘制出甘特图 绘制线性时间图

4总结与回顾

通过这次实验，我学到了很多东西，教务管理系统是学校的管理核心，管理应涉及到学校的专业设置、学藉管理、成绩管理、网上注册、开课管理、选课管理、师资管理等，在数据库一级建立强有力的安全系统，管理人员可以在互联网的任何地方办工，

真正实现学校网上管理。

学校中的教务管理是一项很重要的工作，包括学生管理，教师管理和课程管理等。开发“教务信息处理系统”的目的就是利用计算机的查询和运算功能，代替手工处理，提高工作效力和质量，所以该系统是必要而且能够实现的。

此次开发的软件是教务管理系统的一个子系统，即学院课程安排。通过此次课程设计，我们更加了解了软件的原理，软件的开发方法和步骤，如绘制数据流图和数据字典的编写。进一步掌握了有关数据库设计的知识和java程序设计，了解了有关网络的相关知识，对软件开发平台有了一定了解。我增长了不少软件工程与编程，数据库的知识。在作设计的过程中，软件是不断变化的，开始构造的是一方面，实际制作时又是另外一方面，所以得不断变化。软件必须有效的支持他的用户，我们做的软件是学生选课系统，所以我们需要从学生和老师，管理员的实际情况出发，制定他们操作方便的系统，是软件对用户友好。

在写数据字典之前，我对数据字典的理解有一些偏差，通过这次作实验，我知道了数据字典就是对数据流，数据流分量，数据存储，处理的定义集合。我们做这种比较小的软件时，数据字典还比较好维护，哪里出了问题，可以很快的找到，然后改正。如果做比较大的软件时，数据字典就不好维护了。开发大的软件系统时，数据字典的规模和复杂程度迅速增加，貌似人工维护就不太可能了。

这次实验的完成是我们小组共同努力的结果，我们每个人都付出了很大的汗水，也让我明白了团队合作是多么的重要，那么大的工作量仅靠一个人的力量是不可能完成的，在以后的工作和学习中一定要重视团队合作的重要性，多与合作伙伴交流，了解每个人的想法，最后大家的想法和在一起就是个很了(本站向你推荐WWw.Haoword.com)不起的工作。也让我认识到软件在我们的生活中越来越重要，我们的生活处处离不开软件，也让我对自己以后的工作有了很深的了解，让我可以向着自己的目标一点点前进。

第四篇：软件工程实验报告

《软件工程》实验报告

专业班级微软it一班

学生姓名

指导教师赵春刚

实验一需求分析

一、实验目的

通过对软件项目的需求分析，掌握需求分析的主要方法和技术，了解需求分析过程。 二、实验要求

自选一个软件项目，应用软件工程中需求分析方法对系统需求进行分析。 三、实验内容

1、项目完成主要功能概述 （1）项目名称

（2）项目完成主要功能

2、项目需求描述（建立需求模型） （友情提示：完成主要的用例模型即可） 四、实验总结

实验二软件设计

一、实验目的

通过对软件项目的软件设计，掌握软件设计的方法的技术，了解软件设计过程。 二、实验要求

针对需求分析所选的项目和功能模块进行。完成软件项目主要概要设计和详细设计。 三、实验内容

1、项目概要设计描述（建立概要设计模型）

（友情提示：完成项目的主要系统结构图（功能模块图）即可）

2、项目详细设计描述（建立详细设计模型）

（友情提示：用流程图或uml相关模型（活动图、时序图等），完成两个模块以上）

四、实验总结

说明：（此实验为可选做，若完成实验成绩加分）

实验三软件测试

一、实验目的

通过对软件项目的测试，掌握软件测试的原理和方法，了解软件测试过程。 二、实验要求

针对需求分析所选的项目和功能模块进行。完成软件项目主要功能模块的测试。 三、实验内容

1、采用主要测试方法描述

2、主要功能模块测试用例设计

四、实验总结

第五篇：软件工程实验要求

软件工程实验要求

要求：

1查询相关资料，要求以某一个项目的进展为实验过程，整个实验过程是讲一个系统的设计过程，比如，学生管理系统，图书馆管理系统，扫雷程序等（举例的不要采用）

2按照软件工程过程，强调设计的过程，主要包括需求分析，总体设计与详细设计，也可以放入测试与维护等环节，其中设计到一些知识点，比如数据库，数据流图，数据字典，程序技术等。

3确定设计的系统后，请各位同学把设计的题目交给学习委员，让学习委员进行调整，要求雷同题目，即相同的系统最多只能2个同学使用。

4实验报告最后打印出来，a4纸，至少5页，需要封面（这个可以下载有江苏理工学院封面的那个东西改一下），封面主要包括题目、姓名、学号等。文字段落等无要求，但布局统一合理，美观舒服为好。

5实验报告要有实验目的，实验步骤，实验心得等基本步骤，自己可以参照成熟的实验报告添加相关的内容。

6下载相关资料时，切忌全篇下载，可以整合，但参考的资料必须比较多，换句话说，你论文中的内容在网上一搜的话，我顶多只能搜到一段，不要一搜就是一大片一样的。

7可以下载一些图表格等元素，但不要全部都是。

8有心的同学可以设计一个网络上找不到的系统，自我分析整个的大概设计过程，改换一种方式表达出来。比如，你们班级的一个管理系统，自我主页的一个设计，一个独一无二的文学欣赏网站等，此类同学请在题目后标注是原创。 9上交时间为下周四下午2点之后，60-210