心得体会

通过这学期<软件工程>这门课程的学习,使我获益良多,作为一名计算机专业的学生, 觉得计算机方面的东西学的实在是太少了,专业知识的浅陋让我感到有点羞愧, 老师告诉我们,我们在做毕业设计时,要根据<软件工程>这门课程中的有关内容来进行文档的撰写,所以在老师让我们写需求分析报告,可行性研究报告以及总体设计报告中,我学到了很多,了解到如何来写毕业设计的有关文档.,然而也通过这门课程的学习, 让我更深一步了解到一个软件不仅仅就是编写程序这么简单,编写程序只不过是开发软件的一个小小部分而已, 以前一直误认为只要会写程序代码就可以了,现在看来是大错特错了,因为软件开发的前期工作是相当复杂而重要的,首先要了解客户的需求,了解开发的这个软件到底是干什么用的,有时甚至要到一个公司,一个部门里去”跟踪”一段时间, 了解开发的这个软件具体有哪些作用、功能,,否则开发出来的软件将不能满足客户的要求; 开发软件还要知道开发的这个软件底可不可行,要进行可行性研究,.还要分析它的成本,效益,最后还要进行一个总体上的设计,所以说在编写程序代码前还要做其大量的工作,并不是我们想象的那么简单.

有时,老师在讲台上面”使劲儿”给我们讲授知识时,我们总是不认真听讲,或者听一会儿之后又走神儿了,虽然每次都想认真听课,都想学到更多的东西,可总是克服不了自己的惰性,,我们都明白,作为一名大三的学生了,更应该有自律性与毅力,更应该努力,学习更多的知识,因为不久之后我们也将踏入社会面临就业的问题,如果没有多大本事,

专业技能不强,的话,我们将很难找到一份较好的工作,再加上现在每年毕业生都那么多,就业压力是如此的大,所以我们一定要利用好在学校这宝贵的机会,学习更多的知识,不断的强化自己.,让自己变得更优秀!

在这门课程的第一章中呢,我们学习到了软件危机方面的有关知识,以及软件过程和软件生存周期,还了解到软件开发过程模型,那么有哪些模型呢,首先有种瀑布模型, 快速原型模型,然后就是螺旋模型,增量模型,喷泉模型等等,这些模型都有各自不同的特点.。我们还学习到软件开发的一些方法,比如结构化方法. 面向数据结构的开发方法. 面向对象的方法.和视觉化开发方法..

对于第二章呢,我们重点学习了可行性研究,系统流程图,以及如何制定软件计划和成本/效益分析,首先,可行性研究是软件生命周期计划阶段中的重要组成部分,在可行性研究中,”问题定义”是相对重要的,不过问题定义阶段的持续时间一般很短,形成的报告文本也相对比较简单；可行性研究包括经济可行性、技术可行性、法律可行性和开发方案选择四个任务；可行性研究的步骤包括系统规模和目标的复查、认真研究现有系统、导出新系统的高层逻辑模型、重新定义问题、导出和评价供选择的方案、推荐方案和行动方针、草拟开发计划、提交文档这八个方面.然后就是系统流程图,我们要知道系统流程图的一些基本符号,了解它们各自的作用,会画系统流程图,,最后就是如何来制定软件计划和进行成本的估算以及效益分析的方法.

同时,第三章也是我们学习的重点,需求分析是在可行性研究的

基础上进行的更细致的分析工作,是软件定义时期的最后一个阶段,是对软件目标及范围的求精和细化.需求分析的基本任务是准确回答”系统必须做什么”这个问题,它的具体任务是确定对系统的综合要求、分析系统的数据要求、导出目标系统的详细逻辑模型、修订系统开发计划、开发原型系统等这几个方面；了解需求分析的原则；以及会写需求规格说明书,需求规格说明书包括引言、任务概述、需求规定、运行环境规定.引言里面又包括编写目的,背景,定义,参考资料；任务概述里面包括目标,用户的特点,假定和约束,需求规定里又包括对功能.性能的规定,输入/输出的要求,数据管理能力、故障处理的要求,运行环境规定里面包括设备,支持软件,接口,控制这几点。还要知道获取需求的方法.

第四、五章就是总体设计和详细设计了, 第四章主要了解了总体设计的任务及过程,总体设计的原理,以及总体设计的常用方法及工具.第五章了解了详细设计的 一些原则,和详细设计的方法及工具等等.最后我们还学习了软件测试的方法和软件测试的相关步骤.

<软件工程>这门课程让我以前对软件片面的认识有了一个很大的提升,让我深刻了解到要做好一个软件方面的项目应该从哪些方面去着手,也让我以后想从事这方面的工作有了一个新的认识.

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

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

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

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

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

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

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

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

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

2、用户群分类

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

3、建立核心队

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

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

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

4、确定使用实例

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

7、分析用户工作流程

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

5、检查问题报告

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

6、需求重用

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

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