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

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

1、本文为本文为 WordWord版本，下载可任意编辑版本，下载可任意编辑需要开发人员的帮助和指导，但是用户与开发人员之间的沟通很简单涌现障碍，忽视了那些被认为是很明显的信息。最末是需求的确认，由于需求的不稳定性往往随着时间的推移产生变动，使之难以确认。需求猎取可能是最困难、最关键、最易出错及最需要沟通沟通的活为了克服以上的问题，需要有组织的执行需求的猎取活动。动。对需求的猎取往往有错误的认识：用户知道需求是什么，我们所要需求猎取活动要完成的任务或者步骤的过程如下：做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，1、编写项目视图和范围文档什么是要完成的，什么样的系统能适合商业需要就

2、可以了，但是事实上系统的需求包括四个不同的层次：业务需求、用户需求和功能需需求猎取并不是想象的这样简约，这条沟通之路布满了荆棘。首先需求求、非功能性需求。业务需求说明白提供应用户新系统的最初利益,猎取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目实现的环节，这样造成了系统目标的混淆。视图与范围文档中予以说明。用户需求文档描述了用户运用产品需要其次是对问题的理解，用户对计算机系统的技能和限制缺乏了解，要完成的任务，这在运用实例文档或方案脚本说明中予以说明。功能任何一个系统都会有许多的用户或者不同类型的用户，每个用户只知道需求

3、定义了开发人员需要实现的软件功能，使得用户能完成他们的任自己需要的系统，而不知道系统的整体状况，他们不知道系统作为一个务，从而满意了业务需求。整体怎么样工作效率更好，也不太清晰那些工作可以交给软件完成，他非功能性需求是用户对系统良好运作提出的期望，包括了易用性、们不清晰需求是什么，或者说如何以一种精确的方式来描述需求，他们第 1 页 共 4 页软件工程实验心得体会软件工程实验心得体会本文为本文为 WordWord版本，下载可任意编辑版本，下载可任意编辑反应速度、容错性、健壮性等等质量属性。需求猎取就是依据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和

4、范围文档就是从高层次上描述系统的业务需求，应当包括高层的产品业务目标，评估问题解决方案的商业和技术可行性,全部的运用实例和功能需求都需要遵从的标准。而范围文档定义了项目产品所包括的全部工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识,整个项目组都应当把留意力集中在项目目标和范围上。2、用户群分类系统用户在许多方面存在着差异，例如：运用系统的频度和程度、应用领域和计算机系统知识、所运用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素养和喜好等等。依据这些差异，你可以把这些不同的用户分成不同的用户类。与 ulm 中 usecase 的actor 概念一样，用户类不

5、肯定都指人，也可以包括其他应用系统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点，并具体描述出它们的性格特点及任务状况，将有助于需求的猎取和系统设计。3、建立核心队通常用户和开发人员不自觉的都有一种我们和他们的想法，产生一种对立关系，把彼此放在对立面，每一方都定义自己的边界，只想自己的利益而忽视对方的想法。他们通过文档、记录和对话来沟通，而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的，不会给双方带来一点好处,良好的沟通关系没有建立导致了误会和忽视重要的信息。只有当双方参加者都明白要胜利自己需要什么，同时也知道要胜利对方需要

6、什么时，才能建立起一种合作关系。为了建立合作关系通常采用一种组队的方式来猎取需求，建立一个由用户代表和开发人员组成的联合小组作为需求猎取的核心队伍。第 2 页 共 4 页本文为本文为 WordWord版本，下载可任意编辑版本，下载可任意编辑联合小组将负责识别需求、分析解决方案和协商分歧，小组成员可以采纳会议、电子邮件、综合办公系统等方式进行沟通，但沟通时应留意以下原那么：小组会议应当由中立方来组织和主持，用户和开发人员都要参与;沟通预先要确定预备和参加的规章;议题要明确并掩盖全部关键点，但信息来源应当自由;沟通目标要明确，并告知全部的成员。4、确定运用实例从用户代表处收集他们将运用系统完成所需

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

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

9、4 页本文为本文为 WordWord版本，下载可任意编辑版本，下载可任意编辑 6、检查问题报告通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及援助的人能为收集需求过程提供极有价值的信息。7、需求重用假如客户要求的功能与已有的系统很相像，那么可查看需求是否有足够的敏捷性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。总结：经过一学期的软工试验，深刻感到其重要性的同时也学到了不少的东西，将对我在今后的软件开发过程中起极大的作用。第 4 页 共 4 页