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

软件工程试验心得体会 软件工程试验心得体会范文 经过这学期软件工程试验的学习，深深 感到用户需求对软件的重要性。成功的软件产品是建 立在成功的需求根底之上的，而高质量的需求来源于 用户与开发人员之间有效的沟通与合作。当用户有一 个问题可以用计算机系统来解决，而开发人员起先帮 助用户解决这个问题，沟通就起先了。 需求获得可能是最困难、最关键、最易出错及最 须要沟通沟通的活动。对需求的获得往往有错误的相 识：用户知道需求是什么，我们所要做的就是和他们 交谈从他们那里得到需求，只要问用户系统的目标特 征，什么是要完成的，什么样的系统能适合商业须要 就可以了，但是事实上需求获得并不是想象的这样简 洁，这条沟通之路布满了荆棘。首先需求获得要定义 问题范围，系统的边界往往是很难明确的，用户不了 解技术实现的微小环节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的实力 和限制缺乏了解，任何一个系统都会有很多的用户或 者不同类型的用户，每个用户只知道自己须要的系统, 而不知道系统的整体状况，他们不知道系统作为一个 整体怎么样工作效率更好，也不太清楚那些工作可以 交给软件完成，他们不清楚需求是什么，或者说如何 以一种精确的方式来描述需求，他们须要开发人员的 帮助和指导，但是用户与开发人员之间的沟通很简洁 出现障碍，忽视了那些被认为是很明显的信息。最终 是需求的确认，因为需求的不稳定性往往随着时间的 推移产生变动，使之难以确认。为了克制以上的问题, 必需有组织的执行需求的获得活动。 需求获得活动要完成的任务或者步骤的过程如 下: 1、编写工程视图和范围文档 系统的需求包括四个不同的层次：业务需求、用 户需求和功能需求、非功能性需求。业务需求说明白 供应给用户新系统的最初利益,反映了组织机构或用 户对系统、产品高层次的目标要求，它们在工程视图 与范围文档中予以说明。用户需求文档描述了用户运 用产品必须要完成的任务，这在运用实例文档或方案 脚本说明中予以说明。功能需求定义了开发人员必需 实现的软件功能，使得用户能完成他们的任务，从而 满足了业务需求。 非功能性需求是用户对系统良好运作提出的期 望，包括了易用性、反响速度、容错性、强健性等等 质量属性。需求获得就是依据系统业务需求去获得系 统用户需求，然后通过需求分析得到系统的功能需求 和非功能需求。工程视图和范围文档就是从高层次上 描述系统的业务需求，应当包括高层的产品业务目标, 评估问题解决方案的商业和技术可行性，全部的运用 实例和功能需求都必需遵从的标准。而范围文档定义 了工程产品所包括的全部工作及产生产品所用的过 程。工程相关人员对工程的目标和范围能达成共识, 整个工程组都应当把留意力集中在工程目标和范围 ±o 2、用户群分类 系统用户在很多方面存在着差异，例如：运用系 统的频度和程度、应用领域和计算机系统学问、所运 用的系统特性、所进展的业务过程、访问权限、地理 上的布局以及个人的素养和喜好等等。依据这些差异, 你可以把这些不同的用户分成不同的用户类。与ULM 中Usecase的Actor概念一样，用户类不必需都指人, 也可以包括其他应用系统、接口或者硬件，这样做使 得与系统边界外的接口也成为系统需求。将用户群分 类并归纳各自特点，并详细描述出它们的特性特点及 任务状况，将有助于需求的获得和系统设计。 3、建立核心队 通常用户和开发人员不自觉的都有一种我们和 他们的想法，产生一种对立关系，把彼此放在对立面, 每一方都定义自己的边界，只想自己的利益而忽视对 方的想法。他们通过文档、记录和对话来沟通，而不 是作为一个合作的整体去识别和确定需求完成任务。 实践证明这样的方法是不正确的，不会给双方带来一 点好处,良好的沟通关系没有建立导致了误会和忽视 重要的.信息。只有当双方参与者都明白要成功自己须 要什么，同时也知道要成功对方须要什么时，才能建 立起一种合作关系。 为了建立合作关系通常接受一种组队的方式来 获得需求，建立一个由用户代表和开发人员组成的联 合小组作为需求获得的核心队伍。联合小组将负责识 别需求、分析解决方案和协商分歧，小组成员可以接 受会议、电子邮件、综合办公系统等方式进展沟通, 但沟通时应留意以下原那么：小组会议应当由中立方 来组织和主持，用户和开发人员都要参与;沟通预先要 确定准备和参与的规那么;议题要明确并覆盖全部关 键点，但信息来源应当自由;沟通目标要明确，并告知 全部的成员。 4、确定运用实例 从用户代表处收集他们将运用系统完成所需任 务的描述，探讨用户与系统间的交互方式和对话要求, 这就是运用实例，一个单一的运用实例可能包括完成 某项任务的很多逻辑相关任务和交互依次。运用实例 方法给需求获得带来的好处来自于该方法是用以任 务为中心和以用户为中心的观点，比